linux-kernel - Re: [Patch 1/1] init: Provide a kernel start parameter to increase pid

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]

Message-ID: <20100421220505.GB2059@sgi.com>
Date:	Wed, 21 Apr 2010 17:05:07 -0500
From:	Jack Steiner <steiner@....com>
To:	Hedi Berriche <hedi@....com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, Mike Travis <travis@....com>,
	Ingo Molnar <mingo@...e.hu>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Robin Holt <holt@....com>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch 1/1] init: Provide a kernel start parameter to increase
	pid_max v2

On Wed, Apr 21, 2010 at 08:12:13PM +0100, Hedi Berriche wrote:
> On Wed, Apr 21, 2010 at 18:54 Alan Cox wrote:
> | Hedi Berriche <hedi@....com> wrote:
> |
> | > I just checked on an *idle* 1664 CPUs system and I can see 26844 tasks, all
> | > but few being kernel threads.
> | 
> | So why have we got 26844 tasks. Isn't that a rather more relevant
> | question.
> 
> OK, here's a rough breakdown of the tasks
> 
>      104 kswapd
>     1664 aio
>     1664 ata
>     1664 crypto
>     1664 events
>     1664 ib_cm
>     1664 kintegrityd
>     1664 kondemand
>     1664 ksoftirqd
>     1664 kstop
>     1664 migration
>     1664 rpciod
>     1664 scsi_tgtd
>     1664 xfsconvertd
>     1664 xfsdatad
>     1664 xfslogd
> 
> that's 25064, omitting the rest as its contribution to the overall total is
> negligible.

Also, our target for the number of cpus is 4096. We are not even halfway there.
(I certainly expect other issues to arise scaling to 4096p but running out of pids
_should_ not be one of them...)



> 
> [[
> 
> Let's also not forget all those ephemeral user space tasks (udev and the likes)
> that will be spawned at boot time on even large systems with even more
> thousands of disks, arguably one might consider hack initrd and similar to work
> around the problem and set pid_max as soon as /proc becomes available but it's
> a bit of a PITA.
> 
> ]]
> 
> | And as I asked before - how does Tejun's work on sanitizing work queues
> | affect this ?
> 
> I'm not familiar with the work in question so I (we) will have to look it up,
> and at it and see whether it's relevant to what we're seeing here. It does sound
> like it might help, to certain extent at least.
> 
> That said, while I am genuinely interested in spending time on this and digging
> further to see whether something has/can be done about keeping under control the
> number of tasks required to comfortably boot a system of this size, I think that
> in the meantime the boot parameter approach is useful in the sense that it addresses
> the immediate problem of being able such systems *without* any risk to break the
> code or alter the default behaviour.
> 
> Cheers,
> Hedi.
> -- 
> Be careful of reading health books, you might die of a misprint.
> 	-- Mark Twain
--
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/