[lkml]   [2008]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH] page reclaim throttle take2
    David Rientjes wrote:
    > On Wed, 27 Feb 2008, KOSAKI Motohiro wrote:
    >>> I disagree, the config option is indeed static but so is the NUMA topology
    >>> of the machine. It represents the maximum number of page reclaim threads
    >>> that should be allowed for that specific topology; a maximum should not
    >>> need to be redefined with yet another sysctl and should remain independent
    >>> of various workloads.
    >> ok.
    >>> However, I would recommend adding the word "MAX" to the config option.
    >> MAX_PARALLEL_RECLAIM_TASK is good word?
    > I'd use _THREAD instead of _TASK, but I'd also wait for Balbir's input
    > because perhaps I missed something in my original analysis that this
    > config option represents only the maximum number of concurrent reclaim
    > threads and other heuristics are used in addition to this that determine
    > the exact number of threads depending on VM strain.

    Things are changing, with memory hot-add remove, CPU hotplug , the topology can
    change and is no longer static. One can create fake NUMA nodes on the fly using
    a boot option as well.

    Since we're talking of parallel reclaims, I think it's a function of CPUs and
    Nodes. I'd rather keep it as a sysctl with a good default value based on the
    topology. If we end up getting it wrong, the system administrator has a choice.
    That is better than expecting him/her to recompile the kernel and boot that. A
    sysctl does not create problems either w.r.t changing the number of threads, no
    hard to solve race-conditions - it is fairly straight forward

    Warm Regards,
    Balbir Singh
    Linux Technology Center

     \ /
      Last update: 2008-02-27 06:57    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean