lkml.org 
[lkml]   [2008]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC][PATCH] lru_add_drain_all() don't use schedule_on_each_cpu()
    From
    Date
    On Mon, 2008-10-27 at 00:51 +0900, KOSAKI Motohiro wrote:
    > >> >> @@ -611,4 +613,8 @@ void __init swap_setup(void)
    > >> >> #ifdef CONFIG_HOTPLUG_CPU
    > >> >> hotcpu_notifier(cpu_swap_callback, 0);
    > >> >> #endif
    > >> >> +
    > >> >> + vm_wq = create_workqueue("vm_work");
    > >> >> + BUG_ON(!vm_wq);
    > >> >> +
    > >> >> }
    > >> >
    > >> > While I really hate adding yet another per-cpu thread for this, I don't
    > >> > see another way out atm.
    > >>
    > >> Can I ask the reason of your hate?
    > >> if I don't know it, making improvement patch is very difficult to me.
    > >
    > > There seems to be no drive to keep them down, ps -def output it utterly
    > > dominated by kernel threads on a freshly booted machine with many cpus.
    >
    > True. but I don't think it is big problem. because
    >
    > 1. people can use grep filter easily.
    > 2. that is just "sense of beauty" issue. not real pain.
    > 3. current ps output is already utterly filled by kernel thread on
    > large server :)
    > the patch doesn't introduce new problem.

    Sure, its already bad, which is why I think we should see to it it
    doesn't get worse - also we could make kthreads use CLONE_PID in which
    case they'd all get collapsed, but that would be a use-visible change
    which might up-set folks even more.

    > > And while they are not _that_ expensive to have around, they are not
    > > free either, I imagine the tiny-linux folks having an interest in
    > > keeping these down too.
    >
    > In my embedded job experience, I don't hear that.
    > Their folks strongly interest to memory size and cpu usage, but don't
    > interest # of thread so much.
    >
    > Yes, too many thread spent many memory by stack. but the patch
    > introduce only one thread on embedded device.

    Right, and would be about 4k+sizeof(task_struct), some people might be
    bothered, but most won't care.

    > Perhaps, I misunderstand your intension. so can you point your
    > previous discussion url?

    my google skillz fail me, but once in a while people complain that we
    have too many kernel threads.

    Anyway, if we can re-use this per-cpu workqueue for more goals, I guess
    there is even less of an objection.


    \
     
     \ /
      Last update: 2008-10-26 17:21    [W:2.063 / U:0.172 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site