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.
