lkml.org 
[lkml]   [2008]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] lru_add_drain_all() don't use schedule_on_each_cpu()
>> >> @@ -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.

> 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.


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


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