* [PATCH] Add possibility to set /dev/tty number
@ 2016-01-04 15:34 Pierre Paul MINGOT
2016-01-04 15:43 ` Greg KH
2016-01-06 13:39 ` Austin S. Hemmelgarn
0 siblings, 2 replies; 22+ messages in thread
From: Pierre Paul MINGOT @ 2016-01-04 15:34 UTC (permalink / raw)
To: gregkh, jslaby, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 514 bytes --]
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. As all these 64
devices are not necessary or mandatory for the kernel proper working,
I add a config option to set the desired tty. The lowest number you
can set is 1 and the highest is 63, any value respectively below or
above that, will cause a kconfig invalid entry pop-up.
Please keep me update.
Best Regards
[-- Attachment #2: 0001-In-Linux-there-is-no-way-to-set-the-number-of-tty-de.patch --]
[-- Type: text/x-patch, Size: 2434 bytes --]
From 430deaf09da90bf0da03b7ca612cd4481ad30fea Mon Sep 17 00:00:00 2001
From: Pierre Paul MINGOT <mingot.pierre@gmail.com>
Date: Thu, 22 Jan 2015 17:51:49 +0100
Subject: [PATCH] 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. As all these 64 devices
are not necessary or mandatory for the kernel proper working, I add a config
option to set the desired tty. The lowest number you can set is 1 and the
highest is 63, any value respectively below or above that, will cause a
kconfig invalid entry pop-up.
Signed-off-by: Pierre Paul MINGOT <mingot.pierre@gmail.com>
---
drivers/tty/Kconfig | 14 ++++++++++++++
include/uapi/linux/vt.h | 4 ++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
index b24aa01..0ec58a2 100644
--- a/drivers/tty/Kconfig
+++ b/drivers/tty/Kconfig
@@ -75,6 +75,19 @@ config VT_CONSOLE_SLEEP
def_bool y
depends on VT_CONSOLE && PM_SLEEP
+config NR_TTY_DEVICES
+ int "Maximum tty device number"
+ depends on VT
+ range 1 63
+ default 1
+ ---help---
+ This is the highest numbered device created in /dev. You will actually have
+ NR_TTY_DEVICES+1 devices in /dev. The default is 63, which will result in
+ 64 /dev entries. The lowest number you can set is 1 and the highest is 63,
+ anything respectively below or above that, is not possible and will cause
+ a kconfig invalid entry pop-up.
+ So the default value will be set.
+
config HW_CONSOLE
bool
depends on VT && !UML
@@ -419,4 +432,5 @@ config DA_CONSOLE
help
This enables a console on a Dash channel.
+
endif # TTY
diff --git a/include/uapi/linux/vt.h b/include/uapi/linux/vt.h
index 978578b..2140496 100644
--- a/include/uapi/linux/vt.h
+++ b/include/uapi/linux/vt.h
@@ -7,8 +7,8 @@
* resizing).
*/
#define MIN_NR_CONSOLES 1 /* must be at least 1 */
-#define MAX_NR_CONSOLES 63 /* serial lines start at 64 */
-#define MAX_NR_USER_CONSOLES 63 /* must be root to allocate above this */
+/* serial lines start at 64 */
+#define MAX_NR_CONSOLES CONFIG_NR_TTY_DEVICES
+/* must be root to allocate above this */
+#define MAX_NR_USER_CONSOLES CONFIG_NR_TTY_DEVICES
/* Note: the ioctl VT_GETSTATE does not work for
consoles 16 and higher (since it returns a short) */
--
1.9.1
^ permalink raw reply related [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 15:34 [PATCH] Add possibility to set /dev/tty number Pierre Paul MINGOT
@ 2016-01-04 15:43 ` Greg KH
2016-01-04 16:57 ` Austin S. Hemmelgarn
2016-01-06 13:39 ` Austin S. Hemmelgarn
1 sibling, 1 reply; 22+ messages in thread
From: Greg KH @ 2016-01-04 15:43 UTC (permalink / raw)
To: Pierre Paul MINGOT; +Cc: jslaby, linux-kernel
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?
> As all these 64
> devices are not necessary or mandatory for the kernel proper working,
> I add a config option to set the desired tty. The lowest number you
> can set is 1 and the highest is 63, any value respectively below or
> above that, will cause a kconfig invalid entry pop-up.
>
> Please keep me update.
Please don't attach patches, I can't do anything with them, you should
include them directly in your email. Also, if you look at your patch:
> From 430deaf09da90bf0da03b7ca612cd4481ad30fea Mon Sep 17 00:00:00 2001
> From: Pierre Paul MINGOT <mingot.pierre@gmail.com>
> Date: Thu, 22 Jan 2015 17:51:49 +0100
> Subject: [PATCH] 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. As all these 64 devices
> are not necessary or mandatory for the kernel proper working, I add a config
> option to set the desired tty. The lowest number you can set is 1 and the
> highest is 63, any value respectively below or above that, will cause a
> kconfig invalid entry pop-up.
The entire changelog entry is in the Subject, which I doubt is what you
want :(
Please fix it up to have a short subject first and resend, after fixing
the errors below as well:
> diff --git a/drivers/tty/Kconfig b/drivers/tty/Kconfig
> index b24aa01..0ec58a2 100644
> --- a/drivers/tty/Kconfig
> +++ b/drivers/tty/Kconfig
> @@ -75,6 +75,19 @@ config VT_CONSOLE_SLEEP
> def_bool y
> depends on VT_CONSOLE && PM_SLEEP
>
> +config NR_TTY_DEVICES
> + int "Maximum tty device number"
> + depends on VT
> + range 1 63
> + default 1
> + ---help---
> + This is the highest numbered device created in /dev. You will actually have
> + NR_TTY_DEVICES+1 devices in /dev. The default is 63, which will result in
> + 64 /dev entries. The lowest number you can set is 1 and the highest is 63,
> + anything respectively below or above that, is not possible and will cause
> + a kconfig invalid entry pop-up.
> + So the default value will be set.
> +
Odd mixture of tabs and spaces, just always use tabs please.
And the default should not be 1, keep it what it is today.
> config HW_CONSOLE
> bool
> depends on VT && !UML
> @@ -419,4 +432,5 @@ config DA_CONSOLE
> help
> This enables a console on a Dash channel.
>
> +
> endif # TTY
> diff --git a/include/uapi/linux/vt.h b/include/uapi/linux/vt.h
> index 978578b..2140496 100644
> --- a/include/uapi/linux/vt.h
> +++ b/include/uapi/linux/vt.h
> @@ -7,8 +7,8 @@
> * resizing).
> */
> #define MIN_NR_CONSOLES 1 /* must be at least 1 */
> -#define MAX_NR_CONSOLES 63 /* serial lines start at 64 */
> -#define MAX_NR_USER_CONSOLES 63 /* must be root to allocate above this */
> +/* serial lines start at 64 */
This doesn't make sense anymore, right?
Are you breaking the serial line minor number with this change?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 15:43 ` Greg KH
@ 2016-01-04 16:57 ` Austin S. Hemmelgarn
2016-01-04 17:11 ` Greg KH
0 siblings, 1 reply; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-04 16:57 UTC (permalink / raw)
To: Greg KH, Pierre Paul MINGOT; +Cc: jslaby, linux-kernel
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).
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).
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.
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 16:57 ` Austin S. Hemmelgarn
@ 2016-01-04 17:11 ` Greg KH
2016-01-04 18:41 ` Austin S. Hemmelgarn
0 siblings, 1 reply; 22+ messages in thread
From: Greg KH @ 2016-01-04 17:11 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: Pierre Paul MINGOT, jslaby, linux-kernel
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?
> 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 :)
> 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?
> 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.
Please provide some "real" numbers of memory savings please before
saying that this change really does save memory. Just guessing isn't
ok.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 17:11 ` Greg KH
@ 2016-01-04 18:41 ` Austin S. Hemmelgarn
2016-01-04 22:55 ` One Thousand Gnomes
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-04 18:41 UTC (permalink / raw)
To: Greg KH; +Cc: Pierre Paul MINGOT, jslaby, linux-kernel
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 18:41 ` Austin S. Hemmelgarn
@ 2016-01-04 22:55 ` One Thousand Gnomes
2016-01-05 13:16 ` Austin S. Hemmelgarn
2016-01-05 8:51 ` Pierre Paul MINGOT
2016-01-05 18:38 ` Austin S. Hemmelgarn
2 siblings, 1 reply; 22+ messages in thread
From: One Thousand Gnomes @ 2016-01-04 22:55 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: Greg KH, Pierre Paul MINGOT, jslaby, linux-kernel
> > 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.
So fix that instead.
And really for low memory embedded why do you even have the VT layer in
your system in the first place ?
> > 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).
We don't do regressions.
> 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.
And those embedded devices can almost certainly save more by just not
including the vt layer.
Alan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 18:41 ` Austin S. Hemmelgarn
2016-01-04 22:55 ` One Thousand Gnomes
@ 2016-01-05 8:51 ` Pierre Paul MINGOT
2016-01-05 13:02 ` Austin S. Hemmelgarn
2016-01-05 15:25 ` Greg KH
2016-01-05 18:38 ` Austin S. Hemmelgarn
2 siblings, 2 replies; 22+ messages in thread
From: Pierre Paul MINGOT @ 2016-01-05 8:51 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: Greg KH, jslaby, linux-kernel
2016-01-04 19:41 GMT+01:00 Austin S. Hemmelgarn <ahferroin7@gmail.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.
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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 8:51 ` Pierre Paul MINGOT
@ 2016-01-05 13:02 ` Austin S. Hemmelgarn
2016-01-05 15:25 ` Greg KH
1 sibling, 0 replies; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-05 13:02 UTC (permalink / raw)
To: Pierre Paul MINGOT; +Cc: Greg KH, jslaby, linux-kernel
On 2016-01-05 03:51, Pierre Paul MINGOT wrote:
> 2016-01-04 19:41 GMT+01:00 Austin S. Hemmelgarn <ahferroin7@gmail.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.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 22:55 ` One Thousand Gnomes
@ 2016-01-05 13:16 ` Austin S. Hemmelgarn
2016-01-05 15:24 ` Greg KH
2016-01-05 16:11 ` Theodore Ts'o
0 siblings, 2 replies; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-05 13:16 UTC (permalink / raw)
To: One Thousand Gnomes; +Cc: Greg KH, Pierre Paul MINGOT, jslaby, linux-kernel
On 2016-01-04 17:55, One Thousand Gnomes wrote:
>>> 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.
>
> So fix that instead.
I never said that it was broken, I was just pointing out that the
overhead is non-zero even when the VT is unused.
>
> And really for low memory embedded why do you even have the VT layer in
> your system in the first place ?
Sometimes this is unavoidable. Any kind of generic system generally
wants the VT layer, and there are a number of low memory embedded
systems that I've seen that depend on the ability to switch VT's for
their software to work correctly.
>
>>> 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).
>
> We don't do regressions.
Requiring only a recompilation isn't a regression, especially when it
works fine without being recompiled, and I have yet to actually see
anything that changing the number of VT's would break other than
ConsoleKit (systemd-logind might also need a rebuild, but I'm not sure
about that, and don't have a system I could test it on).
>
>> 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.
>
> And those embedded devices can almost certainly save more by just not
> including the vt layer.
And a few pages can make a difference on _any_ device, not just an
embedded system. For a purpose specific system, that can be the
difference between fitting the working set in memory and having to hit
swap space.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 13:16 ` Austin S. Hemmelgarn
@ 2016-01-05 15:24 ` Greg KH
2016-01-05 15:33 ` Austin S. Hemmelgarn
2016-01-05 16:11 ` Theodore Ts'o
1 sibling, 1 reply; 22+ messages in thread
From: Greg KH @ 2016-01-05 15:24 UTC (permalink / raw)
To: Austin S. Hemmelgarn
Cc: One Thousand Gnomes, Pierre Paul MINGOT, jslaby, linux-kernel
On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
> >And those embedded devices can almost certainly save more by just not
> >including the vt layer.
> And a few pages can make a difference on _any_ device, not just an embedded
> system. For a purpose specific system, that can be the difference between
> fitting the working set in memory and having to hit swap space.
No one has proven any memory savings yet, so why are you saying this is
noticable?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 8:51 ` Pierre Paul MINGOT
2016-01-05 13:02 ` Austin S. Hemmelgarn
@ 2016-01-05 15:25 ` Greg KH
2016-01-05 15:43 ` Austin S. Hemmelgarn
1 sibling, 1 reply; 22+ messages in thread
From: Greg KH @ 2016-01-05 15:25 UTC (permalink / raw)
To: Pierre Paul MINGOT; +Cc: Austin S. Hemmelgarn, jslaby, linux-kernel
On Tue, Jan 05, 2016 at 09:51:14AM +0100, Pierre Paul MINGOT wrote:
> 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.
> 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.
I don't understand how reducing the number of vt devices makes anything
more or less secure, or better yet, more responsive. Please provide
specific details showing how this happens.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 15:24 ` Greg KH
@ 2016-01-05 15:33 ` Austin S. Hemmelgarn
0 siblings, 0 replies; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-05 15:33 UTC (permalink / raw)
To: Greg KH; +Cc: One Thousand Gnomes, Pierre Paul MINGOT, jslaby, linux-kernel
On 2016-01-05 10:24, Greg KH wrote:
> On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
>>> And those embedded devices can almost certainly save more by just not
>>> including the vt layer.
>> And a few pages can make a difference on _any_ device, not just an embedded
>> system. For a purpose specific system, that can be the difference between
>> fitting the working set in memory and having to hit swap space.
>
> No one has proven any memory savings yet, so why are you saying this is
> noticable?
I didn't mean to imply that the VT subsystem itself was necessarily
responsible for any space savings, I simply intended to point out that
savings of a few pages can make a difference.
On that note though, I think I've got something that should work to
check this across a couple of different configurations, so I'll
hopefully have results soon.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 15:25 ` Greg KH
@ 2016-01-05 15:43 ` Austin S. Hemmelgarn
2016-01-05 16:03 ` Greg KH
0 siblings, 1 reply; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-05 15:43 UTC (permalink / raw)
To: Greg KH, Pierre Paul MINGOT; +Cc: jslaby, linux-kernel
On 2016-01-05 10:25, Greg KH wrote:
> On Tue, Jan 05, 2016 at 09:51:14AM +0100, Pierre Paul MINGOT wrote:
>> 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.
>> 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.
>
> I don't understand how reducing the number of vt devices makes anything
> more or less secure, or better yet, more responsive. Please provide
> specific details showing how this happens.
WRT security, the argument isn't that it makes the system inherently
more secure, but that it makes it easier to prove the system is secure
because there are fewer unused device nodes in /dev that you need to
explain. In a way, it's a different aspect of the argument that
reducing the number of VT's makes /dev less cluttered. I don't
personally agree with doing hardware auditing via /dev, but that's a
separate discussion.
As far as the argument about hot-plug overhead, that is an issue (albeit
a very small one) because that's at least 30+ extra uevents for devices
that will likely never be used, but it's only an issue during boot
unless you're doing crazy stuff with allocating and freeing VT's all the
time. My statement in my reply to this particular message still applies
though, if you're _that_ timing constrained, you should be using a real
RTOS (Linux can do RT, but it's not optimal for it, especially with any
of the regularly used userspace implementations).
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 15:43 ` Austin S. Hemmelgarn
@ 2016-01-05 16:03 ` Greg KH
0 siblings, 0 replies; 22+ messages in thread
From: Greg KH @ 2016-01-05 16:03 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: Pierre Paul MINGOT, jslaby, linux-kernel
On Tue, Jan 05, 2016 at 10:43:45AM -0500, Austin S. Hemmelgarn wrote:
> >I don't understand how reducing the number of vt devices makes anything
> >more or less secure, or better yet, more responsive. Please provide
> >specific details showing how this happens.
> WRT security, the argument isn't that it makes the system inherently more
> secure, but that it makes it easier to prove the system is secure because
> there are fewer unused device nodes in /dev that you need to explain.
No, the "proof" is the same no matter how many vt device nodes you have.
> In a
> way, it's a different aspect of the argument that reducing the number of
> VT's makes /dev less cluttered. I don't personally agree with doing
> hardware auditing via /dev, but that's a separate discussion.
It's not a discussion, it's a fallacy.
> As far as the argument about hot-plug overhead, that is an issue (albeit a
> very small one) because that's at least 30+ extra uevents for devices that
> will likely never be used, but it's only an issue during boot unless you're
> doing crazy stuff with allocating and freeing VT's all the time.
How long do those 30+ extra uevents at boot time take? Can you really
measure that? Especially given that they aren't even being sent to
userspace because you don't have a running userspace at that point in
time?
> My statement in my reply to this particular message still applies
> though, if you're _that_ timing constrained, you should be using a
> real RTOS (Linux can do RT, but it's not optimal for it, especially
> with any of the regularly used userspace implementations).
RT slows down your machine, so you are not making any sense at all here.
Anyway, why are we even arguing? There's not a usable patch even
present here to discuss....
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 13:16 ` Austin S. Hemmelgarn
2016-01-05 15:24 ` Greg KH
@ 2016-01-05 16:11 ` Theodore Ts'o
2016-01-05 16:22 ` Austin S. Hemmelgarn
1 sibling, 1 reply; 22+ messages in thread
From: Theodore Ts'o @ 2016-01-05 16:11 UTC (permalink / raw)
To: Austin S. Hemmelgarn, G
Cc: One Thousand Gnomes, Greg KH, Pierre Paul MINGOT, jslaby, linux-kernel
On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
> >We don't do regressions.
> Requiring only a recompilation isn't a regression, especially when it works
> fine without being recompiled, and I have yet to actually see anything that
> changing the number of VT's would break other than ConsoleKit
> (systemd-logind might also need a rebuild, but I'm not sure about that, and
> don't have a system I could test it on).
Sorry, breaking a compiled binary is a regression.
People have outlined more clever ways of trying to accomplish your
goal (saving memory) without breaking other people. I suggest you
give that a try instead of just trying to defend your existing patch.
- Ted
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 16:11 ` Theodore Ts'o
@ 2016-01-05 16:22 ` Austin S. Hemmelgarn
0 siblings, 0 replies; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-05 16:22 UTC (permalink / raw)
To: Theodore Ts'o, G, One Thousand Gnomes, Greg KH,
Pierre Paul MINGOT, jslaby, linux-kernel
On 2016-01-05 11:11, Theodore Ts'o wrote:
> On Tue, Jan 05, 2016 at 08:16:52AM -0500, Austin S. Hemmelgarn wrote:
>>> We don't do regressions.
>> Requiring only a recompilation isn't a regression, especially when it works
>> fine without being recompiled, and I have yet to actually see anything that
>> changing the number of VT's would break other than ConsoleKit
>> (systemd-logind might also need a rebuild, but I'm not sure about that, and
>> don't have a system I could test it on).
>
> Sorry, breaking a compiled binary is a regression.
>
> People have outlined more clever ways of trying to accomplish your
> goal (saving memory) without breaking other people. I suggest you
> give that a try instead of just trying to defend your existing patch.
>
First, it's not my patch.
Second, my usage of the term 'break' was probably not the best choice
here, as ConsoleKit doesn't stop working. All that happens is that it
spits out some warnings about not finding VT's that it thinks should be
there. All that recompiling gets you is that it stops it from spitting
out these warnings, which could just as easily be suppressed by other
means. And, while I can't personally test this, I'm pretty certain that
the same applies to systemd-logind. They have to gracefully cope with
not being able to see all the VT's they think they should, because it's
fully possible for something to hook into early boot and deallocate most
of them before ConsoleKit or logind run.
Third, as Greg stated in his response to the patch, it should be updated
so that the default matches current behavior, which would mean that
nothing would break unless the person building the kernel chose to break it.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 18:41 ` Austin S. Hemmelgarn
2016-01-04 22:55 ` One Thousand Gnomes
2016-01-05 8:51 ` Pierre Paul MINGOT
@ 2016-01-05 18:38 ` Austin S. Hemmelgarn
2016-01-05 20:47 ` One Thousand Gnomes
2 siblings, 1 reply; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-05 18:38 UTC (permalink / raw)
To: Greg KH; +Cc: Pierre Paul MINGOT, jslaby, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]
On 2016-01-04 13:41, Austin S. Hemmelgarn wrote:
> On 2016-01-04 12:11, Greg KH wrote:
>> 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.
As promised, I've got numbers regarding the memory impact.
The system used for testing was a para-virtualized Xen domain running a
Linux kernel built from these sources:
git://github.com/Ferroin/linux.git
using the attached base config.
The domain used for testing was given 4096 MB or RAM, 4 VCPUS, a PV NIC,
2 PV disks, and had migration restrictions disabled (nomigrate=1 in the
domain configuration file).
I tested stock sources with the VT subsystem enabled, stock sources with
the VT subsystem disabled, and locally modified sources with
MAX_NR_CONSOLES and MAX_USER_NR_CONSOLES manually changed to 31.
The testing involved booting each configuration 8 times, and comparing
the MemTotal line form /proc/meminfo. None of the tests included any
userspace initialization of the VT's.
Results were 100% stable across each reboot for a given configuration.
Having the full VT subsystem built in, MemTotal showed 4097176 Kb of RAM.
The manually modified version with half the number of VT's showed
4097228 Kb or RAM.
With the entire VT subsystem compiled out, MemTotal was 4097304 Kb.
This means that not including the VT subsystem resulted in a 128k
reduction in runtime footprint, and having only half the number of VT's
resulted in a 52k reduction. Assuming a linear correlation between the
number of VT's and the runtime footprint of the subsystem, that means
the subsystem itself incurs 26k of overhead, and each VT incurs
approximately 1.6k of overhead.
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 12169 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 18:38 ` Austin S. Hemmelgarn
@ 2016-01-05 20:47 ` One Thousand Gnomes
2016-01-06 12:42 ` Austin S. Hemmelgarn
0 siblings, 1 reply; 22+ messages in thread
From: One Thousand Gnomes @ 2016-01-05 20:47 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: Greg KH, Pierre Paul MINGOT, jslaby, linux-kernel
> This means that not including the VT subsystem resulted in a 128k
> reduction in runtime footprint, and having only half the number of VT's
> resulted in a 52k reduction. Assuming a linear correlation between the
> number of VT's and the runtime footprint of the subsystem, that means
> the subsystem itself incurs 26k of overhead, and each VT incurs
> approximately 1.6k of overhead.
Doesn't seem an unreasonable value - so yes you've made an argument for
dynamically allocating the vt structures when they are first referenced.
Alan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-05 20:47 ` One Thousand Gnomes
@ 2016-01-06 12:42 ` Austin S. Hemmelgarn
2016-01-06 13:54 ` One Thousand Gnomes
0 siblings, 1 reply; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-06 12:42 UTC (permalink / raw)
To: One Thousand Gnomes; +Cc: Greg KH, Pierre Paul MINGOT, jslaby, linux-kernel
On 2016-01-05 15:47, One Thousand Gnomes wrote:
>> This means that not including the VT subsystem resulted in a 128k
>> reduction in runtime footprint, and having only half the number of VT's
>> resulted in a 52k reduction. Assuming a linear correlation between the
>> number of VT's and the runtime footprint of the subsystem, that means
>> the subsystem itself incurs 26k of overhead, and each VT incurs
>> approximately 1.6k of overhead.
>
> Doesn't seem an unreasonable value - so yes you've made an argument for
> dynamically allocating the vt structures when they are first referenced.
No, I've made an argument for finding some way to reduce the runtime
impact of the VT subsystem. Dynamic allocation is one way to do that,
but not the only way.
In fact, there already appears to be some degree of allocation on demand
for VT's (otherwise deallocvt has no point), just not for everything
associated with the VT. I'd be willing to bet that almost everything
that reasonably can be dynamically allocated already is, there is a bare
minimum required for even a virtual device after all.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-04 15:34 [PATCH] Add possibility to set /dev/tty number Pierre Paul MINGOT
2016-01-04 15:43 ` Greg KH
@ 2016-01-06 13:39 ` Austin S. Hemmelgarn
1 sibling, 0 replies; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-06 13:39 UTC (permalink / raw)
To: Pierre Paul MINGOT, gregkh, jslaby, linux-kernel
On 2016-01-04 10:34, 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. As all these 64
> devices are not necessary or mandatory for the kernel proper working,
> I add a config option to set the desired tty. The lowest number you
> can set is 1 and the highest is 63, any value respectively below or
> above that, will cause a kconfig invalid entry pop-up.
>
> Please keep me update.
>
> Best Regards
>
OK, circling back since I never commented on the original patch. Greg covered most of the basics regarding formatting, so I won't comment on that.
>+config NR_TTY_DEVICES
>+ int "Maximum tty device number"
>+ depends on VT
>+ range 1 63
>+ default 1
The config item should default to the current value of 63, as it changes the userspace visible ABI otherwise. It should also probably depend on EXPERT, as this isn't something that should be arbitrarily changed by most people building the kernel.
> #define MIN_NR_CONSOLES 1 /* must be at least 1 */
>-#define MAX_NR_CONSOLES 63 /* serial lines start at 64 */
>-#define MAX_NR_USER_CONSOLES 63 /* must be root to allocate above this */
>+/* serial lines start at 64 */
>+#define MAX_NR_CONSOLES CONFIG_NR_TTY_DEVICES
>+/* must be root to allocate above this */
>+#define MAX_NR_USER_CONSOLES CONFIG_NR_TTY_DEVICES
This shouldn't affect serial console numbering, as the minimum serial console minor number isn't defined relative to either of the values here.
Using #define to define things relative to Kconfig values in uapi headers doesn't work (at least, not just doing it with a simple #define, there might be some way to do it, but I have yet to see it), these would need to get parsed when the headers get installed, so this patch would result in MAX_NR_CONSOLES and MAX_NR_USER_CONSOLES being undefined in the userspace headers because userspace doesn't have direct access to any of the CONFIG values.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-06 12:42 ` Austin S. Hemmelgarn
@ 2016-01-06 13:54 ` One Thousand Gnomes
2016-01-06 14:07 ` Austin S. Hemmelgarn
0 siblings, 1 reply; 22+ messages in thread
From: One Thousand Gnomes @ 2016-01-06 13:54 UTC (permalink / raw)
To: Austin S. Hemmelgarn; +Cc: Greg KH, Pierre Paul MINGOT, jslaby, linux-kernel
> In fact, there already appears to be some degree of allocation on demand
> for VT's (otherwise deallocvt has no point), just not for everything
> associated with the VT. I'd be willing to bet that almost everything
> that reasonably can be dynamically allocated already is, there is a bare
> minimum required for even a virtual device after all.
If there is 1.6K overhead per vt coming from somewhere (given we only
preallocate 1 VT) then either
- There is stuff not being dynamically allocated (which you can find and
fix)
- Your userspace is triggering those dynamic allocations
There is no magic thing that requires 1.6K of kernel data per console.
Alan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH] Add possibility to set /dev/tty number
2016-01-06 13:54 ` One Thousand Gnomes
@ 2016-01-06 14:07 ` Austin S. Hemmelgarn
0 siblings, 0 replies; 22+ messages in thread
From: Austin S. Hemmelgarn @ 2016-01-06 14:07 UTC (permalink / raw)
To: One Thousand Gnomes; +Cc: Greg KH, Pierre Paul MINGOT, jslaby, linux-kernel
On 2016-01-06 08:54, One Thousand Gnomes wrote:
>> In fact, there already appears to be some degree of allocation on demand
>> for VT's (otherwise deallocvt has no point), just not for everything
>> associated with the VT. I'd be willing to bet that almost everything
>> that reasonably can be dynamically allocated already is, there is a bare
>> minimum required for even a virtual device after all.
>
> If there is 1.6K overhead per vt coming from somewhere (given we only
> preallocate 1 VT) then either
>
> - There is stuff not being dynamically allocated (which you can find and
> fix)
>
> - Your userspace is triggering those dynamic allocations
>
> There is no magic thing that requires 1.6K of kernel data per console.
There is a bare minimum structure required for something to be
associated with a device node. The device nodes exist regardless, and
the dynamic allocation of the other things (like the screen state, the
output buffer, etc) gets triggered on first access to the node. 1.6k is
probably not the absolute minimum it could be, but there are still
things that need to be there for it to behave the way it's supposed to.
At a minimum, you need stuff to associate the device numbers, handle
the tty ioctls, handle device node access, and probably an associated
lock or two to maintain consistency. None of that can reasonably be
dynamically allocated without multiplexing everything through a single
underlying virtual device (kind of like is done with PTY's) or adding
some new system calls to manage it, except that that would change the
userspace API, and thus be a regression.
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2016-01-06 14:07 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-04 15:34 [PATCH] Add possibility to set /dev/tty number Pierre Paul MINGOT
2016-01-04 15:43 ` Greg KH
2016-01-04 16:57 ` Austin S. Hemmelgarn
2016-01-04 17:11 ` Greg KH
2016-01-04 18:41 ` Austin S. Hemmelgarn
2016-01-04 22:55 ` One Thousand Gnomes
2016-01-05 13:16 ` Austin S. Hemmelgarn
2016-01-05 15:24 ` Greg KH
2016-01-05 15:33 ` Austin S. Hemmelgarn
2016-01-05 16:11 ` Theodore Ts'o
2016-01-05 16:22 ` Austin S. Hemmelgarn
2016-01-05 8:51 ` Pierre Paul MINGOT
2016-01-05 13:02 ` Austin S. Hemmelgarn
2016-01-05 15:25 ` Greg KH
2016-01-05 15:43 ` Austin S. Hemmelgarn
2016-01-05 16:03 ` Greg KH
2016-01-05 18:38 ` Austin S. Hemmelgarn
2016-01-05 20:47 ` One Thousand Gnomes
2016-01-06 12:42 ` Austin S. Hemmelgarn
2016-01-06 13:54 ` One Thousand Gnomes
2016-01-06 14:07 ` Austin S. Hemmelgarn
2016-01-06 13:39 ` Austin S. Hemmelgarn
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.