public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Albert Cahalan <albert@users.sf.net>
To: linux-kernel mailing list <linux-kernel@vger.kernel.org>
Cc: akpm@osdl.org, hpa@zytor.com
Subject: Re: something funny about tty's on 2.6.4-rc1-mm1
Date: 02 Mar 2004 23:12:00 -0500	[thread overview]
Message-ID: <1078287119.2255.403.camel@cube> (raw)

Andrew Morton writes:

> The (untested) first-fit patch I proposed uses
> a radix tree, so it should in fact be faster
> than the old code.
>
> Are you now thinking that we might need to
> change the pty allocator?

I just re-read Edgar Toernig's comment... oh yeah.
Contemplate BOTH parts of the utmp quote:

: char ut_id[4];     /* init id or abbrev. ttyname */
: ...
: xterm(1) and other terminal emulators directly create
: a USER_PROCESS record and generate the ut_id by using
: the last two letters of /dev/ttyp%c or by using p%d
: for /dev/pts/%d. If they find a DEAD_PROCESS for this
: id, they recycle it, otherwise they create a new entry.

The utmp or utmpx record is about 1/2 a kilobyte.
The records get added to a file. They only get
recycled when the tty is recycled.

So that's a 20 bit minor, 9 bits of utmpx record size...
and thus a file that grows to half a gigabyte.

The reasons are adding up quickly:

1. half-gigabyte utmp,wtmp,wtmpx,utmpx file
2. breaks ut_id, even if 1000 ptys not used
3. a pain to type ("ps -t 1018493")
4. screws up column widths (ps, w, top...)
5. breaks old dev_t, even if 256 ttys not used



             reply	other threads:[~2004-03-03  4:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-03  4:12 Albert Cahalan [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-03-02 19:04 something funny about tty's on 2.6.4-rc1-mm1 Albert Cahalan
2004-03-02 19:54 ` H. Peter Anvin
2004-03-02 22:46 ` Edgar Toernig
2004-03-02 23:59   ` H. Peter Anvin
2004-03-01 18:45 Nuno Monteiro
2004-03-01 19:09 ` Richard B. Johnson
2004-03-02  5:47 ` H. Peter Anvin
2004-03-02 14:52   ` James H. Cloos Jr.
2004-03-02 15:02     ` Richard B. Johnson
2004-03-02 17:47       ` James H. Cloos Jr.
2004-03-02 16:54     ` H. Peter Anvin
2004-03-02 22:08       ` Andrew Morton
2004-03-03  2:29         ` H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1078287119.2255.403.camel@cube \
    --to=albert@users.sf.net \
    --cc=akpm@osdl.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox