linux-kernel - Re: [RFC][PATCH] lru_add_drain_all() don't use schedule_on_each

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Oct 2008 00:51:41 +0900
From:	"KOSAKI Motohiro" <kosaki.motohiro@...fujitsu.com>
To:	"Peter Zijlstra" <peterz@...radead.org>
Cc:	"Heiko Carstens" <heiko.carstens@...ibm.com>,
	"Nick Piggin" <npiggin@...e.de>, linux-kernel@...r.kernel.org,
	"Hugh Dickins" <hugh@...itas.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Rik van Riel" <riel@...hat.com>,
	"Lee Schermerhorn" <lee.schermerhorn@...com>, linux-mm@...ck.org,
	"Christoph Lameter" <cl@...ux-foundation.org>,
	"Gautham Shenoy" <ego@...ibm.com>,
	"Oleg Nesterov" <oleg@...sign.ru>,
	"Rusty Russell" <rusty@...tcorp.com.au>, mpm <mpm@...enic.com>
Subject: Re: [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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/