Message-ID: <568ABCBD.3070909@gmail.com>
Date:	Mon, 4 Jan 2016 13:41:01 -0500
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	Greg KH <gregkh@...uxfoundation.org>
Cc:	Pierre Paul MINGOT <mingot.pierre@...il.com>, jslaby@...e.cz,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add possibility to set /dev/tty number

On 2016-01-04 12:11, Greg KH wrote:
> On Mon, Jan 04, 2016 at 11:57:33AM -0500, Austin S. Hemmelgarn wrote:
>> On 2016-01-04 10:43, Greg KH wrote:
>>> On Mon, Jan 04, 2016 at 04:34:56PM +0100, Pierre Paul MINGOT wrote:
>>>> Hello,
>>>>
>>>> In Linux there is no way to set the number of tty devices or console
>>>> to create. By default the kernel create 64 /dev/tty devices. what is
>>>> too much for embedded system with limited resources.
>>>
>>> Really?  How much memory does a vt device take up?
>> On a device with a simple text mode console in 80x25, a minimum of 2000
>> bytes, not including anything used for character attributes, and anything
>> else needed for the display and updating of the screen (I think I worked out
>> once that it comes out to about 8k).  On my laptop which has a 1920x1080
>> screen, using the standard 8x16 VGA font with a framebuffer console via
>> i915, I get a 200x67 terminal size, which means that just the text without
>> any attributes works out to a little more than 13k.  That gets doubled just
>> by adding color, and probably doubled again for the other display
>> attributes.  All of this also doesn't factor in the space taken up in
>> devtmpfs and sysfs by the associated files (it's not much, but it's still
>> wasted space).
>
> If the console isn't initialized by userspace, is any of that space
> still really being used?  Have you tried that?
I'm pretty certain that most of the space that gets taken up by the 
scrollback buffer and screen isn't directly used unless the console is 
used, but there are still structures that get allocated at driver 
instantiation for each VT, including the device structures and such.
>
>> That said, there are factors to consider other than just memory footprint:
>> 1. Having 64 tty devices in /dev leads to somewhat cluttered listings (on
>> most small systems I see, more than two thirds of the contents of /dev are
>> tty device nodes).
>
> Not having a cluttered /dev isn't the best reasoning here :)
It wasn't intended as an argument on it's own, simply an additional 
point.  It does have an impact though if you're dealing with something 
like a slow serial console, and it also looks _really_ odd having a 
bunch of device nodes for virtual devices that aren't used, and on most 
systems you can't get rid of at runtime (I've always been under the 
impression that having a dynamic /dev was primarily to avoid all the 
clutter you see there on systems like BSD (most derivatives of which 
still use a statically initialized /dev)).
>
>> 2. Most people don't know how to switch to anything higher than about tty
>> 15, a majority of people who have a graphical environment use at most 2
>> VT's, and a lot of embedded systems use a fixed number of VT's that is known
>> prior to full production.
>
> Agreed, but does this actually take up memory?
My point here was more that high numbered VT's are something that's 
pretty much unused on most systems, and therefore there is almost zero 
benefit for a majority of people.  At the very least it takes up space 
for the driver internal structures, and the stuff in sysfs.  While a few 
Kb of memory may not seem like much given that servers with close to 1Tb 
of RAM are starting to become common, it can still make a lot of 
difference in performance for a small embedded system.
>
>> 3. There is some very poorly designed software out there (at least the
>> original version of ConsoleKit, and I'd be willing to bet some third-party
>> vendor software) which unconditionally starts a thread or process for each
>> VT in the system.  While this software should be fixed to behave properly,
>> it's infeasible for most end users to do this.
>
> If we remove the number of devices, those "broken" userspace programs
> will also break, so that implies that we should not allow this change.
No, the software should just need to be recompiled (I've tested this 
with ConsoleKit, which also fails gracefully when it tires to open a tty 
device that doesn't exist), or adapted to dynamically detect the number 
of TTYs (like it should have in the first place for portability reasons).
>
> Please provide some "real" numbers of memory savings please before
> saying that this change really does save memory.  Just guessing isn't
> ok.
I can probably put something together to actually test this, but it will 
take a while (most of my testing scripts and VM's are targeted at 
regression testing of filesystems, not memory profiling of virtual 
device drivers). I doubt that it will work out to any more than 16k size 
difference, but that's still a few more pages (on most systems) that 
could be used for other things.
--
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