Message-ID: <568BBECD.9020301@gmail.com>
Date:	Tue, 5 Jan 2016 08:02:05 -0500
From:	"Austin S. Hemmelgarn" <ahferroin7@...il.com>
To:	Pierre Paul MINGOT <mingot.pierre@...il.com>
Cc:	Greg KH <gregkh@...uxfoundation.org>, jslaby@...e.cz,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Add possibility to set /dev/tty number

On 2016-01-05 03:51, Pierre Paul MINGOT wrote:
> 2016-01-04 19:41 GMT+01:00 Austin S. Hemmelgarn <ahferroin7@...il.com>:
>> 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.
>
>
> I totally agree with the points evoked by Austin. Nevertheless, the
> interests of this patch are not  ONLY memory consumption or
> performance related.
> In industrial sector, for obvious security and safety reasons we want
> configure our system and have a full control of the devices within it.
> So unused or dummy devices are not wanted , not nice to have.
>   One way to achieve this goal is to have a full picture of the devices
> in our system and then identified which type of applications can run
> and then safety or security potential risks. Base on this analysis we
> can put in place mandatory actions to fix the risks.
I actually hadn't thought of the security auditing aspect, although 
there are arguably much better ways to do hardware auditing than listing 
/dev.
> An other interest for reduce dummy /dev devices is hot-plug device
> creation detection through inotify or udev. Indeed, we can configure
> udev or inotify for monitoring the /dev directory and notify watched
> dedicated events. lesser the devices in /dev is better the response
> is. This aspect is crucial for RTOS with very high time constraint
> near of microseconds. It's the case for example for a system with
> Linux RT Patch or Xenomai.
Unless you're mucking around with binding and unbinding VT's, hot-plug 
overhead from VT's is only an issue at boot, and there are much better 
ways to reduce the amount of time it takes to boot.  Most of the time it 
takes to boot a significant majority of Linux systems is either in 
hardware initialization done by the firmware before even loading Linux, 
or in the userspace init scripts.  As an example of this, the Thinkpad 
L540 laptop I use at the moment for work takes about 60 seconds to go 
from hitting the power button to having a login prompt.  About 20% of 
that time is spent in either the firmware or GRUB, and roughly 70% of 
that time is spent running init scripts.  Most of the time in init 
scripts is NetworkManager starting up, but even if I cut that out, the 
init scripts still take roughly 55% of the time.  Once, shortly after I 
got the hardware, I decided to try running with a static /dev.  It saved 
me rougly 2 seconds of time, and based on the profiling I did, all of 
that was just because of the backlog of uevents, not the number.

If you're really so timing constrained that you can't handle a couple of 
seconds during boot, you should be using a real RTOS like RTEMS or TRON, 
or at least something a lot more lightweight than Linux.
--
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