| 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
| ||
|
Date: Fri, 6 Apr 2007 05:43:01 -0500 From: Robin Holt <holt@....com> To: "Eric W. Biederman" <ebiederm@...ssion.com> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, Chris Snook <csnook@...hat.com>, Robin Holt <holt@....com>, Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org, Jack Steiner <steiner@...ricas.sgi.com> Subject: Re: init's children list is long and slows reaping children. > So I think we have some options once we get the kernel threads out > of the way. Getting the kernel threads out of the way would seem > to be the first priority. I think both avenues would probably be the right way to proceeed. Getting kthreads to not be parented by init would be an opportunity for optimization. I think organizing the zombie tasks to be easily reaped also has merit. Rapidly forking/exiting processes like udevd during the boot of a different machine were also shown to benefit significantly from this patch. That machine had 512 cpus and 4608 disk devices, we dropped the device discovery under udevd by 30%. This, honestly, surprised us. It makes some sense now that I think about it. This would be a case where improving the zombie handling would be beneficial to more than just kthreads. Thanks, Robin - 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/
Powered by blists - more mailing lists