[lkml]   [2000]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: PIDs limited to 15 significant bits
David Weinehall writes:
> On Sun, Oct 01, 2000 at 01:10:50AM -0400, Albert D. Cahalan wrote:
>> Andries Brouwer writes:
>>> On Fri, Sep 29, 2000 at 03:57:10PM -0400, Albert D. Cahalan wrote:

>>>> What do you think of "ps -efj" on a standard 80x24 screen?
>>> I never give such commands, but just tried:
>>> aeb 119876 1 426 236 0 23:32 tty1 00:00:00 xterm
>>> aeb 119877 119876 119877 119877 0 23:32 pts/9 00:00:00 -bash
>>> aeb 119884 119877 119884 119877 0 23:33 pts/9 00:00:00 ps -efj
>>> as you see, the ps program here fails to align the columns,
>>> but otherwise all is well.
>> How are you going to like the output after some more uptime?
>> The record is around 1200 days I think. With a faster machine
>> doing a lot of work, you could just about lose the CMD column.
> So, let's see if I get this straight: you want us to limit PID's to
> 15 bits rather than 31 bits because the output of ps wouldn't look nice
> otherwise?! PLEASE...

This reason is as good as any. Remember, nobody has yet
actually run out of PID space. When that happens, then
there is a legitimate need to increase PID space.

I see you don't remember the original post. It argued in
favor of a large PID space "because the output of ps wouldn't
look nice otherwise"!!! (the poster wanted output sorted by
start time without using --sort=start to ask for it)

> Should we stick to 16 bit UID's because a simple
> "ls -nal" might look ugly?! Oh, and du/df will probably start to look
> ugly when having those 2 TB sized LV's. Oh my... Better return to non
> LFS.

If one really NEEDS large numbers, then the limit must go.
I really don't want to see "ls -nal" spit out 10-digit numbers
unless I really have a billion users.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:39    [W:0.044 / U:26.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site