Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1614606 > unrolled thread

[PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-02 00:40 +0200
    Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-02 15:30 +0200
      Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-02 18:00 +0200
        Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Alan Cox <alan@linux.intel.com> - 2017-04-03 15:00 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 18:10 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Alan Cox <alan@linux.intel.com> - 2017-04-03 20:10 +0200
              Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 22:00 +0200
                Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Alan Cox <alan@linux.intel.com> - 2017-04-04 15:50 +0200
                  Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-04 21:30 +0200
    Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems Andi Kleen <andi@firstfloor.org> - 2017-04-02 22:50 +0200
      Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-02 23:50 +0200
        Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Stuart Longland <stuartl@longlandclan.id.au> - 2017-04-03 01:00 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 03:10 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Stuart Longland <stuartl@longlandclan.id.au> - 2017-04-04 02:50 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-03 20:20 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Rob Herring <robh@kernel.org> - 2017-04-03 21:00 +0200
              Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Geert Uytterhoeven <geert@linux-m68k.org> - 2017-04-03 21:50 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-03 23:10 +0200
              Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Tom Zanussi <tom.zanussi@linux.intel.com> - 2017-04-04 19:00 +0200
                Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-04 19:10 +0200
                  Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Tom Zanussi <tom.zanussi@linux.intel.com> - 2017-04-04 20:00 +0200
                    Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-04 20:10 +0200
                      Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-04 20:40 +0200
                      Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Tom Zanussi <tom.zanussi@linux.intel.com> - 2017-04-04 22:00 +0200
                        Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-04 22:30 +0200
                Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-04 21:00 +0200
        Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andy Shevchenko <andy.shevchenko@gmail.com> - 2017-04-03 10:00 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Andi Kleen <andi@firstfloor.org> - 2017-04-03 17:40 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 19:30 +0200
            Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Adam Borowski <kilobyte@angband.pl> - 2017-04-03 22:00 +0200
              Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 22:10 +0200
                Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Adam Borowski <kilobyte@angband.pl> - 2017-04-03 22:40 +0200
          Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Nicolas Pitre <nicolas.pitre@linaro.org> - 2017-04-03 18:50 +0200
    Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for  embedded systems Greg Kroah-Hartman <gregkh@linuxfoundation.org> - 2017-04-03 09:50 +0200

Page 2 of 2 — ← Prev page 1 [2]

#1616274 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
> 
> > Yes, in a previous project, I had been working toward getting a < 1M
> > system to boot on Galileo hardware (which it did, but using more than
> > that - the Galileo2 has 256MB, but it was the target hardware at the
> > time, and I was hoping eventually to be able to boot out of the 512k
> > on-chip SRAM).
> >
> > I was focused at that point mainly on the kernel static size, and using
> > a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> > net-diet patches, and my own miscellaneous patches that I was planning
> > on eventually upstreaming, I ended up with a system that I could boot to
> > shell with a 455k text size:
> >
> > Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> > 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
> >
> > virtual kernel memory layout:
> >     fixmap  : 0xfffe5000 - 0xfffff000   ( 104 kB)
> >     vmalloc : 0xd05f0000 - 0xfffe3000   ( 761 MB)
> >     lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
> >       .init : 0xc1094000 - 0xc10b5000   ( 132 kB)
> >       .data : 0xc1071fac - 0xc1092760   ( 129 kB)
> >       .text : 0xc1000000 - 0xc1071fac   ( 455 kB)
> >
> > That was without networking.  Enabling networking added about 250k, and
> > at that point I could ssh in and run a webserver, still less than 1M as
> > far as kernel static size, which of course completely ignores the kernel
> > dynamic size and userspace.
> 
> Thanks for sharing your experience. The question closer to this
> discussion what did you do against TTY/UART/(related) layer(s)?
> 

I'd have to go back and take a look, but nothing special AFIAR.

No patches or hacks along those lines, and the only related thing I see
as far as config is:
	
	cfg/pty-disable.scc \

which maps to:

	# CONFIG_UNIX98_PTYS is not set

[toc] | [prev] | [next] | [standalone]

#1616294 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
>> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
>> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:

>> > I was focused at that point mainly on the kernel static size, and using
>> > a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
>> > net-diet patches, and my own miscellaneous patches that I was planning
>> > on eventually upstreaming, I ended up with a system that I could boot to
>> > shell with a 455k text size:
>> >
>> > Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
>> > 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)

>> Thanks for sharing your experience. The question closer to this
>> discussion what did you do against TTY/UART/(related) layer(s)?
>>
>
> I'd have to go back and take a look, but nothing special AFIAR.
>
> No patches or hacks along those lines, and the only related thing I see
> as far as config is:
>
>         cfg/pty-disable.scc \
>
> which maps to:
>
>         # CONFIG_UNIX98_PTYS is not set

But on your guestimation how much can we squeeze TTY/UART layer if we
do some compile-time configuration?
Does it even make sense or better to introduce something like minitty
special layer instead?

I believe you did some research during time of that project…

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1616306 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, 4 Apr 2017, Andy Shevchenko wrote:

> On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> > On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> >> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> >> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
> 
> >> > I was focused at that point mainly on the kernel static size, and using
> >> > a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> >> > net-diet patches, and my own miscellaneous patches that I was planning
> >> > on eventually upstreaming, I ended up with a system that I could boot to
> >> > shell with a 455k text size:
> >> >
> >> > Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> >> > 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
> 
> >> Thanks for sharing your experience. The question closer to this
> >> discussion what did you do against TTY/UART/(related) layer(s)?
> >>
> >
> > I'd have to go back and take a look, but nothing special AFIAR.
> >
> > No patches or hacks along those lines, and the only related thing I see
> > as far as config is:
> >
> >         cfg/pty-disable.scc \
> >
> > which maps to:
> >
> >         # CONFIG_UNIX98_PTYS is not set
> 
> But on your guestimation how much can we squeeze TTY/UART layer if we
> do some compile-time configuration?
> Does it even make sense or better to introduce something like minitty
> special layer instead?

For the record I more or less came along the same path as Tom, playing 
with LTO, gc-sections, syscall removal, module_param() removal, etc. At 
the end of the day you still have that 45K of TTY code just to send 
debug out, 100K of VFS even if using only ramfs, 54K of timer code even 
if there's only one simple timer available, 28K of IRQ support code even 
if there is only one type of interrupt used, etc. LTO / gc-section 
cannot automatically get rid of those unused functions because they're 
runtime selected callbacks and optimization tools no longer can do their 
magic.

At some point there is no way other than having a parallel 
implementation specifically for a limited scope to reduce both code 
footprint and runtime RAM consumption. Who need a multicore scalable VFS 
cache when there's only 256K of RAM and a single user space process 
running?


Nicolas

[toc] | [prev] | [next] | [standalone]

#1616367 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Tue, 2017-04-04 at 21:04 +0300, Andy Shevchenko wrote:
> On Tue, Apr 4, 2017 at 8:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> > On Tue, 2017-04-04 at 20:08 +0300, Andy Shevchenko wrote:
> >> On Tue, Apr 4, 2017 at 7:59 PM, Tom Zanussi <tom.zanussi@linux.intel.com> wrote:
> >> > On Tue, 2017-04-04 at 00:05 +0300, Andy Shevchenko wrote:
> 
> >> > I was focused at that point mainly on the kernel static size, and using
> >> > a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> >> > net-diet patches, and my own miscellaneous patches that I was planning
> >> > on eventually upstreaming, I ended up with a system that I could boot to
> >> > shell with a 455k text size:
> >> >
> >> > Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> >> > 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
> 
> >> Thanks for sharing your experience. The question closer to this
> >> discussion what did you do against TTY/UART/(related) layer(s)?
> >>
> >
> > I'd have to go back and take a look, but nothing special AFIAR.
> >
> > No patches or hacks along those lines, and the only related thing I see
> > as far as config is:
> >
> >         cfg/pty-disable.scc \
> >
> > which maps to:
> >
> >         # CONFIG_UNIX98_PTYS is not set
> 
> But on your guestimation how much can we squeeze TTY/UART layer if we
> do some compile-time configuration?
> Does it even make sense or better to introduce something like minitty
> special layer instead?
> 
> I believe you did some research during time of that project…
> 

Yes, as a matter of fact I did, and just found some notes I took at the
time.  I didn't dive into the code in detail - that level of analysis
was supposed to come later but I did have these notes mentioning that I
thought it would show the largest savings for a single item (outside of
networking) 'if we could do it':

"- Largest is still drivers

- drivers/tty and serial is the biggest obvious win if we can do it
  - break down into granular config options
    - leave simplest possible tty/serial functionality
    - allow tailoring to specific hardware
  - also helps in effort to get rid of char devices
  - 65740/815190"

Basically 65k out of an 800k text size could be partially or mostly
saved by addressing that one item, which looks like it pretty much
matches Nicolas' numbers...

So no doubt it would be worthwhile to address one way or the other.
Whether to do that by refactoring the tty layer or partial refactoring
and creation of a parallel minimal version would best be left up to
someone who actually understands it I would think...

BTW, since I'm quoting my own notes on the subject, I thought I'd just
include the whole thing, which covers a bunch of other areas possibly
ripe for tinification, in case anyone might be interested (some of it
should be taken with a grain of salt though ;-)

Tom

--------

galileo SMALLEST_SIZE

$ size vmlinux
   text	          data			       bss	    dec	    hex	filename
 699668		   186432		       2271592	    3157692  302ebc	vmlinux

Not using this, because
 $ size xxx.o shows all 0s with LTO

----

Using this:

galileo SMALLEST_SIZE with LTO off

$ size vmlinux
   text	          data			       bss	    dec	    hex	filename
 815190		   165696		       2272760	    3253646  31a58e	vmlinux

This corresponds to LTO size:

$ size vmlinux
   text	          data			       bss	    dec	    hex	filename
 677183		   179528		       1207280	    2063991  1f7e77	vmlinux

$ ls -al arch/x86/boot/bzImage 
-rw-r--r--. 1 427264 Mar 12 22:34 arch/x86/boot/bzImage

And booted size:

Memory: 235388K/245240K available (534K kernel code, 100K rwdata, 52K rodata, 14
8K init, 64K bss, 3172K reserved, 0K cma-reserved)
virtual kernel memory layout:
    fixmap  : 0xfffa4000 - 0xfffff000   ( 364 kB)
    vmalloc : 0xd05f0000 - 0xfffa2000   ( 761 MB)
    lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
      .init : 0xc10af000 - 0xc10d4000   ( 148 kB)
      .data : 0xc1085b9c - 0xc10ad120   ( 157 kB)
      .text : 0xc1000000 - 0xc1085b9c   ( 534 kB)

------
Totals - details below
------

- make ptrace configurable - this should help the hw breakpoints and x86 perf disable patches upstream
  - 5k
- remove things not needed for CONFIG_SMP
  - 5k
- support configuring out kswapd
  - about 5k in vmscan
- support configuring out vmstat
  - 0
- kernel capabilities
  - 1k
- exec domains
  - 1k
- tsc
     3030	    284	     40	   3354	    d1a	./arch/x86/kernel/tsc.o
    332		          0        0	        332	    14c	./arch/x86/kernel/tsc_msr.o
- support configuring out signals
  11852	       36           4	  11892	   2e74	./kernel/signal.o
   3188	             1	          0	      3189	    c75	./arch/x86/kernel/signal.o
  - about 15k
- kernel/pid.o simplification - more for dynamic memory - simpler pidhash
  1868	    160	      4	   2032	    7f0	./kernel/pid.o
  - about 2k
- remove kernel/exit.o
  - assume processes never exit
- remove lib/kfifo
  - about 2k
- remove kernel/irq/spurious
  - about 1k
- make sys configurable
  - about 7k
- remove xattr
  - about 4k
- /drivers total possible savings, some percentage of:
  - 136000/815190
- /kernel savings
  - say 30000/815190 savings
- /fs savings
  - 30000/815190 savings
- /arch/x86 savings
  - 20000/815190
- /mm
  - 5000/815190
- /lib
  - 10000/815190

Totals without mmu:
  146k + (2/3)*136k = 235k

  235k/815190 = 30% savings

- x86 nommu
  - about 50k

Totals with mmu:

  285k/815190 = 35% savings


Applied to the 534k boot figure, we end up with text size of:

  374k mmu
  347k nommu

We could probably go lower with more fine-grained analysis, but we may
also need to add drivers, etc.

-----
NONET details
-----

- Largest is still drivers

- drivers/tty and serial is the biggest obvious win if we can do it
  - break down into granular config options
    - leave simplest possible tty/serial functionality
    - allow tailoring to specific hardware
  - also helps in effort to get rid of char devices
  - 65740/815190 

- pci is next largest
  - assume we can break down into granular config options
    - leave simplest possible pci functionality
    - allow tailoring to specific hardware e.g. no discovery
  - 47144/815190

- drivers/base
  - simplify driver core for a small set of drivers
    - simple_char: New infrastructure to simplify chardev management
  - 25389/815190

- total possible savings, some percentage of:
  - 136000/815190

 206992	  29331	   6556	 242879	  3b4bf	./drivers/built-in.o

 65740	  16888	   3132	  85760	  14f00	./drivers/tty/built-in.o
 32077	  16680	   2688	  51445	   c8f5	./drivers/tty/serial/built-in.o
 21628	  15892	   2644	  40164	   9ce4	./drivers/tty/serial/8250/built-in.o
  47144	   1172	   2100	  50416	   c4f0	./drivers/pci/built-in.o
  25389	   1324	    112	  26825	   68c9	./drivers/base/built-in.o
  15733	    636	     20	  16389	   4005	./drivers/spi/built-in.o
  11504	    136	     28	  11668	   2d94	./drivers/clk/built-in.o
   9605	    460	     72	  10137	   2799	./drivers/thermal/built-in.o
   5066	    624	    912	   6602	   19ca	./drivers/char/built-in.o
   8531	    480	     36	   9047	   2357	./drivers/i2c/built-in.o

- 2nd largest is kernel

  - should be able to cut *something* from time and sched
    - we have a handful of processes at most
    - we have very simple time needs
  - say 30000/815190 savings

 150742	   6376	   8209	 165327	  285cf	./kernel/built-in.o

  40951	   1105	   4720	  46776	   b6b8	./kernel/time/built-in.o
  21760	   1318	    112	  23190	   5a96	./kernel/sched/built-in.o
   9800	    388	   1328	  11516	   2cfc	./kernel/irq/built-in.o
   4956	      4	      4	   4964	   1364	./kernel/locking/built-in.o
   1847	     88	    184	   2119	    847	./kernel/printk/built-in.o
   1757	     33	      0	   1790	    6fe	./kernel/rcu/built-in.o
   1408	    356	     44	   1808	    710	./kernel/power/built-in.o

- next is fs

  - completely turn off proc
    - requires userspace changes to cope with it
    - 22046/815190, 100% of this

  - simplify/featurize some core vfs?
    - e.g. namei, small set of file names, no need for complexity

  - disable vfs completely?
    - init reads executables directly from storage
    - all state in memory, no need to save anything

 133526	   1506	   1552	 136584	  21588	./fs/built-in.o
  22046	    140	     40	  22226	   56d2	./fs/proc/built-in.o

- next is arch/x86, mostly in arch/x86/kernel
  - not much to save here, maybe 10 here and there
  - maybe 3k in boot: video*
  - maybe 5k in cpu: amd, transmeta, cachinfo, etc
  - cut about 10k in arch/x86/mm for nommu

 120755	  50209	  52712	 223676	  369bc	./arch/x86/built-in.o

 100201	  29261	  19828	 149290	  2472a	./arch/x86/kernel/built-in.o

  21713	   8693	    720	  31126	   7996	./arch/x86/kernel/cpu/built-in.o
  17480	   5486	   6324	  29290	   726a	./arch/x86/kernel/apic/built-in.o
  10385	   4365	    532	  15282	   3bb2	./arch/x86/kernel/cpu/mcheck/built-in.o

  18237	    208	  30776	  49221	   c045	./arch/x86/mm/built-in.o
  14276	    412	    256	  14944	   3a60	./arch/x86/pci/built-in.o
   1345	      8	     28	   1381	    565	./arch/x86/platform/intel-quark/built-in.o
   1345	      8	     28	   1381	    565	./arch/x86/platform/built-in.o
    590	   8228	     16	   8834	   2282	./arch/x86/vdso/built-in.o
    379	  12500	      8	  12887	   3257	./arch/x86/realmode/built-in.o
    477	      0	      0	    477	    1dd	./arch/x86/lib/built-in.o

- next is mm
 
  - cut about 5k for percpu
  - cut about 40k for nommu

 119008	  13688	   1824	 134520	  20d78	./mm/built-in.o

   1358	      0        0	     1358	    54e	./mm/gup.o
  10612	     32	      24       10668	       29ac	./mm/memory.o
   1072	      0        0     1072	           430	./mm/mincore.o
   2453	      0        0		      2453	    995	./mm/mlock.o
   9918	    176        8	        10102	       2776	./mm/mmap.o
   1403	      0	      0		   1403	           57b	./mm/mprotect.o
   2155	      0          0	      2155	       86b	./mm/mremap.o
    520	      0          0       520	           208	./mm/msync.o
   4358	      0	        8    4366	      110e	./mm/rmap.o
   6355	      57	     28		         6440	   1928	./mm/vmalloc.o
    710	      0          0		     710       2c6	./mm/pagewalk.o
     92	      0	         0	          92        5c	./mm/pgtable-generic.o

- next is lib

  - no need for vsprintf if printk off, 10k

  30654	  24647	      5	  55306	   d80a	./lib/built-in.o

   9964	      0	      0	   9964	   26ec	./lib/zlib_inflate/built-in.o

-next is init

   8456	  16437	     81	  24974	   618e	./init/built-in.o



----
Net sizes, maybe later...

galileo SMALLEST_SIZE_NET with LTO off

- this is without ipv4 net-diet
- includes ipv6

$ size vmlinux
   text	          data			       bss	    dec	    hex	filename
1368973		   181184		       2288560	    3838717  3a92fd	vmlinux

---
NET details
---


- net now largest, larger than drivers (and drivers goes up too)

 465384	  13818	  17364	 496566	  793b6	./net/built-in.o

 183144	   5409	   7948	 196501	  2ff95	./net/ipv4/built-in.o
 128583	   4648	   6432	 139663	  2218f	./net/ipv6/built-in.o
 108158	   2092	   2804	 113054	  1b99e	./net/core/built-in.o
  15268	    264	      0	  15532	   3cac	./net/packet/built-in.o
  14787	    465	    148	  15400	   3c28	./net/netlink/built-in.o
   4011	    676	      0	   4687	   124f	./net/sched/built-in.o
    967	     12	      0	    979	    3d3	./net/ethernet/built-in.o

- drivers second largest

 255026	  30512	   6604	 292142	  4752e	./drivers/built-in.o

    359	     20	      0	    379	    17b	./drivers/reset/built-in.o
   2155	    152	     32	   2339	    923	./drivers/pps/built-in.o
   8870	    580	      0	   9450	   24ea	./drivers/net/phy/built-in.o
  42421	    861	      8	  43290	   a91a	./drivers/net/built-in.o
  30650	    233	      8	  30891	   78ab	./drivers/net/ethernet/stmicro/stmmac/built-in.o
  30650	    233	      8	  30891	   78ab	./drivers/net/ethernet/stmicro/built-in.o
  30650	    233	      8	  30891	   78ab	./drivers/net/ethernet/built-in.o
  47144	   1172	   2100	  50416	   c4f0	./drivers/pci/built-in.o
  11504	    136	     28	  11668	   2d94	./drivers/clk/built-in.o
  25389	   1324	    112	  26825	   68c9	./drivers/base/built-in.o
  15733	    636	     20	  16389	   4005	./drivers/spi/built-in.o
   5066	    624	    912	   6602	   19ca	./drivers/char/built-in.o
   9931	    548	     76	  10555	   293b	./drivers/thermal/built-in.o
   4927	    224	     36	   5187	   1443	./drivers/ptp/built-in.o
  65740	  16888	   3132	  85760	  14f00	./drivers/tty/built-in.o
  32077	  16680	   2688	  51445	   c8f5	./drivers/tty/serial/built-in.o
  21628	  15892	   2644	  40164	   9ce4	./drivers/tty/serial/8250/built-in.o
   8531	    480	     36	   9047	   2357	./drivers/i2c/built-in.o

- kernel next

 157407	   6376	   8209	 171992	  29fd8	./kernel/built-in.o

   9800	    388	   1328	  11516	   2cfc	./kernel/irq/built-in.o
  40951	   1105	   4720	  46776	   b6b8	./kernel/time/built-in.o
   6665	      0	      0	   6665	   1a09	./kernel/bpf/built-in.o
   1408	    356	     44	   1808	    710	./kernel/power/built-in.o
  21760	   1318	    112	  23190	   5a96	./kernel/sched/built-in.o
   4956	      4	      4	   4964	   1364	./kernel/locking/built-in.o
   1757	     33	      0	   1790	    6fe	./kernel/rcu/built-in.o
   1847	     88	    184	   2119	    847	./kernel/printk/built-in.o

- fs next

 134562	   1534	   1552	 137648	  219b0	./fs/built-in.o

   1395	    276	      4	   1675	    68b	./fs/ramfs/built-in.o
  22743	    168	     40	  22951	   59a7	./fs/proc/built-in.o
   1446	     44	      8	   1498	    5da	./fs/devpts/built-in.o

- arch/x86 next

 120755	  50209	  52712	 223676	  369bc	./arch/x86/built-in.o

    379	  12500	      8	  12887	   3257	./arch/x86/realmode/built-in.o
  14276	    412	    256	  14944	   3a60	./arch/x86/pci/built-in.o
    590	   8228	     16	   8834	   2282	./arch/x86/vdso/built-in.o
  18237	    208	  30776	  49221	   c045	./arch/x86/mm/built-in.o
    477	      0	      0	    477	    1dd	./arch/x86/lib/built-in.o
   1345	      8	     28	   1381	    565	./arch/x86/platform/intel-quark/built-in.o
   1345	      8	     28	   1381	    565	./arch/x86/platform/built-in.o
  17480	   5486	   6324	  29290	   726a	./arch/x86/kernel/apic/built-in.o
  21713	   8693	    720	  31126	   7996	./arch/x86/kernel/cpu/built-in.o
  10385	   4365	    532	  15282	   3bb2	./arch/x86/kernel/cpu/mcheck/built-in.o
 100201	  29261	  19828	 149290	  2472a	./arch/x86/kernel/built-in.o

- mm next

 119008	  13688	   1824	 134520	  20d78	./mm/built-in.o

- lib next

  33042	  24647	      5	  57694	   e15e	./lib/built-in.o

   9964	      0	      0	   9964	   26ec	./lib/zlib_inflate/built-in.o

- crypto next

  30068	    284	      0	  30352	   7690	./crypto/built-in.o

- init next

   8456	  16437	     81	  24974	   618e	./init/built-in.o

[toc] | [prev] | [next] | [standalone]

#1616372 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

[Multipart message — attachments visible in raw view] — view raw

On Tue, 4 Apr 2017, Tom Zanussi wrote:

> On Tue, 2017-04-04 at 21:04 +0300, Andy Shevchenko wrote:
> > I believe you did some research during time of that project…
> > 
> 
> Yes, as a matter of fact I did, and just found some notes I took at the
> time.  I didn't dive into the code in detail - that level of analysis
> was supposed to come later but I did have these notes mentioning that I
> thought it would show the largest savings for a single item (outside of
> networking) 'if we could do it':
> 
> "- Largest is still drivers
> 
> - drivers/tty and serial is the biggest obvious win if we can do it
>   - break down into granular config options
>     - leave simplest possible tty/serial functionality
>     - allow tailoring to specific hardware
>   - also helps in effort to get rid of char devices
>   - 65740/815190"
> 
> Basically 65k out of an 800k text size could be partially or mostly
> saved by addressing that one item, which looks like it pretty much
> matches Nicolas' numbers...

One thing on x86 that inflates the size is the 8250 driver itself. I'm 
looking at some ARM targets with their own UART whose driver is much 
smaller.

> BTW, since I'm quoting my own notes on the subject, I thought I'd just
> include the whole thing, which covers a bunch of other areas possibly
> ripe for tinification, in case anyone might be interested (some of it
> should be taken with a grain of salt though ;-)
> 
[...]
> 
> - 2nd largest is kernel
> 
>   - should be able to cut *something* from time and sched
>     - we have a handful of processes at most
>     - we have very simple time needs
>   - say 30000/815190 savings
> 
>  150742	   6376	   8209	 165327	  285cf	./kernel/built-in.o
> 
>   40951	   1105	   4720	  46776	   b6b8	./kernel/time/built-in.o

Commit baa73d9e47 allows for shaving off 25K here. More could probably 
be done.

>   21760	   1318	    112	  23190	   5a96	./kernel/sched/built-in.o

I already have an alternative scheduler implementation that weights 9K. 
It is on the backburner for now though. But don't let the scheduler 
guys know just yet.  ;-)


Nicolas

[toc] | [prev] | [next] | [standalone]

#1616337 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

[Multipart message — attachments visible in raw view] — view raw

On Tue, 4 Apr 2017, Tom Zanussi wrote:

> Yes, in a previous project, I had been working toward getting a < 1M
> system to boot on Galileo hardware (which it did, but using more than
> that - the Galileo2 has 256MB, but it was the target hardware at the
> time, and I was hoping eventually to be able to boot out of the 512k
> on-chip SRAM).
> 
> I was focused at that point mainly on the kernel static size, and using
> a combination of Josh Triplett's tinification tree, Andi Kleen's LTO and
> net-diet patches, and my own miscellaneous patches that I was planning
> on eventually upstreaming, I ended up with a system that I could boot to
> shell with a 455k text size:
> 
> Memory: 235636K/245176K available (455K kernel code, 61K rwdata,
> 64K rodata, 132K init, 56K bss, 3056K reserved, 0K cma-reserved)
> 
> virtual kernel memory layout:
>     fixmap  : 0xfffe5000 - 0xfffff000   ( 104 kB)
>     vmalloc : 0xd05f0000 - 0xfffe3000   ( 761 MB)
>     lowmem  : 0xc0000000 - 0xcfdf0000   ( 253 MB)
>       .init : 0xc1094000 - 0xc10b5000   ( 132 kB)
>       .data : 0xc1071fac - 0xc1092760   ( 129 kB)
>       .text : 0xc1000000 - 0xc1071fac   ( 455 kB)
> 
> That was without networking.  Enabling networking added about 250k, and
> at that point I could ssh in and run a webserver, still less than 1M as
> far as kernel static size, which of course completely ignores the kernel
> dynamic size and userspace.
> 
> My goal was to get rid of shell access and dropbear altogether and have
> all access be via webserver, which I did by using nostromo, mainly for
> convenience, until I could get some 'cgi' added to Alan Cox's µWeb
> (about 20k).
> 
> Anyway, that work, as I left it a couple years ago, is here, in case
> anyone's interested (it's a yocto layer and yocto-based kernel
> containing many topic branches, but building it according to the
> directions in the README will yield a standard kernel and .config in the
> working directory and allow you to ignore all the yocto stuff): 
> 
> https://github.com/tzanussi/linux-yocto-micro-4.1  
> https://github.com/tzanussi/meta-microlinux/tree/jethro

Thanks for sharing I'll certainly have a look.

> It's nice to see tinification work being done again - at the time I
> stopped working on it it seemed there was no desire from maintainers in
> general to merge anything that would create new options designed only
> for the purpose of tinification.

I successfully provided an option to disable POSIX timers lately. A 
round trip into the Kconfig parser was required to achieve that though.

Many maintainers are resistant to change as their role is to preserve 
stability of their code. Adding special cases in existing code makes it 
much harder to maintain and validate. Sometimes it is way better to have 
a parallel implementation rather that destabilizing the one version 
available... as long as the interface is the same and that the big and 
tiny versions can be used interchangeably.

> In fact, as a kind of backup plan for that, I also played around with
> the idea of auto-generating a kernel that would contain only the
> functions that were demonstrated to be used by the (single-purpose)
> workload.  It was similar to the idea of making every system call
> configurable and then including only the ones used by the workload, but
> taking it a step further and doing that for every function in the
> kernel, not just system calls.

I thought about that too... and dismissed the idea as being too 
frightening!

> I had a script that would take the output of the function_hist histogram
> taken while exhaustively running the workload:
> 
>   https://lkml.org/lkml/2015/5/20/994
> 
> And with a kernel compiled using -ffunction-sections removing all
> functions that were never referenced.  I never got a bootable kernel out
> of it, but mainly just because I ran out of time and had to move onto
> other things.  I may dust it off and try again, just for fun... ;-)

That would be great.

I really wish to stir up interest from more people and have Linux gain 
momentum in the tiny system space.


Nicolas

[toc] | [prev] | [next] | [standalone]

#1614955 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 3, 2017 at 12:41 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Sun, 2 Apr 2017, Andi Kleen wrote:
>> No PTYs seems like a big limitation. This means no sshd?

> Again, my ultimate system target is in the sub-megabyte of RAM.  I
> really doubt you'll be able to fit an SSH server in there even if PTYs
> were supported, unless sshd (or dropbear) can be made really tiny.

Are you sure you need Linux there? There is a nice Zephyr project
(OpenSource RTOS, POSIX compatible) exactly for microcontrollers.

While I can agree on making Linux stuff less fatty, I can't agree on
doing this way. We have for now two subsystems to serve for serial
devices, you are proposing third one for only narrow class of devices.
From my point of view is better to achive your goal with existing
system (as a proof of concept maybe even with ugly #ifdef:fery).

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [next] | [standalone]

#1615338 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

> While I can agree on making Linux stuff less fatty, I can't agree on
> doing this way. We have for now two subsystems to serve for serial
> devices, you are proposing third one for only narrow class of devices.

It should be actually most (all?) real serial ones.

> From my point of view is better to achive your goal with existing
> system (as a proof of concept maybe even with ugly #ifdef:fery).

I like the idea of mintty (if it supported ptys).

Except for that (and possibly VT) it is unlikely that people really
rely on the obsolete terminal features from the 70ies. So it's a kind
of cleanup.

-Andi

[toc] | [prev] | [next] | [standalone]

#1615436 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, 3 Apr 2017, Andi Kleen wrote:

> I like the idea of mintty (if it supported ptys).

In fact PTYs could probably be implemented like another UART driver for 
the master side.

But that may come later.

> Except for that (and possibly VT) it is unlikely that people really
> rely on the obsolete terminal features from the 70ies. So it's a kind
> of cleanup.

I wouldn't push for replacing the existing code though. It is stable and 
full featured. The mini version may well never be fully standard 
compliant to keep the code small.


Nicolas

[toc] | [prev] | [next] | [standalone]

#1615528 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> Except for that (and possibly VT) it is unlikely that people really
> rely on the obsolete terminal features from the 70ies. So it's a kind
> of cleanup.

But... but... but what shall we do without OLCUC?!?

I guess sending these features to the pasture would be nice even in
mainstream TTY.  Probably even without a Kconfig option to restore them.

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!

[toc] | [prev] | [next] | [standalone]

#1615530 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, 3 Apr 2017, Adam Borowski wrote:

> On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> > Except for that (and possibly VT) it is unlikely that people really
> > rely on the obsolete terminal features from the 70ies. So it's a kind
> > of cleanup.
> 
> But... but... but what shall we do without OLCUC?!?
> 
> I guess sending these features to the pasture would be nice even in
> mainstream TTY.  Probably even without a Kconfig option to restore them.

Thing is... those arcane features don't take much code at all:

		if (O_OLCUC(tty))
			c = toupper(c);

That's it. I didn't make the minitty code 5x smaller just by omitting 
those.  ;-)


Nicolas

[toc] | [prev] | [next] | [standalone]

#1615542 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, Apr 03, 2017 at 04:09:38PM -0400, Nicolas Pitre wrote:
> On Mon, 3 Apr 2017, Adam Borowski wrote:
> 
> > On Mon, Apr 03, 2017 at 08:31:03AM -0700, Andi Kleen wrote:
> > > Except for that (and possibly VT) it is unlikely that people really
> > > rely on the obsolete terminal features from the 70ies. So it's a kind
> > > of cleanup.
> > 
> > But... but... but what shall we do without OLCUC?!?
> > 
> > I guess sending these features to the pasture would be nice even in
> > mainstream TTY.  Probably even without a Kconfig option to restore them.
> 
> Thing is... those arcane features don't take much code at all:
> 
> 		if (O_OLCUC(tty))
> 			c = toupper(c);
> 
> That's it. I didn't make the minitty code 5x smaller just by omitting 
> those.  ;-)

Except, those two lines have two bugs:
* it mangles most non-ASCII (kernel's toupper() hard-codes ISO-8859-1
  which no one uses anymore)
* it mangles a number of ANSI codes, making them unusable on any vt100ish
  terminal (ie, any post-1980)

I just happened to send an April Fools pull request
(https://github.com/kilobyte/linux.git runes) in which the first commit
fixes these:
https://github.com/kilobyte/linux/commit/268cde7c6dde54fcbc81df68d66b2389d77d01f2

Even though it's a real fix (unlike the subsequent fun), guess why I'm not
sending it to Greg and Jiri...

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄⠀⠀⠀⠀ preimage for double rot13!

[toc] | [prev] | [next] | [standalone]

#1615414 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Mon, 3 Apr 2017, Andy Shevchenko wrote:

> On Mon, Apr 3, 2017 at 12:41 AM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > On Sun, 2 Apr 2017, Andi Kleen wrote:
> >> No PTYs seems like a big limitation. This means no sshd?
> 
> > Again, my ultimate system target is in the sub-megabyte of RAM.  I
> > really doubt you'll be able to fit an SSH server in there even if PTYs
> > were supported, unless sshd (or dropbear) can be made really tiny.
> 
> Are you sure you need Linux there? There is a nice Zephyr project
> (OpenSource RTOS, POSIX compatible) exactly for microcontrollers.

I know that Zephyr is LF endorsed, aim to slow fragmentation in that 
space, etc.  But it is in itself yet another RTOS. It doesn't look like 
it is really POSIX compatible yet, and is certainly not Linux 
compatible.

I don't pretend that Linux should always be preferred to Zephyr. For 
example, I don't think Linux could ever be used with 32KB of RAM while 
Zephyr easily can.  However, in the hundreds of KB of RAM, given the 
choice between Linux and anything else, I can tell you that many people 
would go with Linux.

The goal is really to be able to leverage the existing Linux knowledge 
and ecosystem. Be able to develop your application on your PC 
workstation, singlestep it, strace it, validate the tiny version of 
those kernel subsystems there too with existing fuzers, etc.  If a 
security issue turns up in your product, you have plenty of people who 
are already familiar with the Linux environment, much more than Zephyr 
or any other RTOSes.

> While I can agree on making Linux stuff less fatty, I can't agree on
> doing this way. We have for now two subsystems to serve for serial
> devices, you are proposing third one for only narrow class of devices.
> From my point of view is better to achive your goal with existing
> system (as a proof of concept maybe even with ugly #ifdef:fery).

Been there already. It doesn't work. The #ifdef:fery in the existing 
code simply doesn't cut it. Because of its flexibility, the existing 
code constitutes a stack of many layers each with its own interface and 
buffering. It uses much more runtime memory simply because it can afford 
it on all existing systems supported by Linux. It can drive a large bank 
of modems without a single hiccup if you're still into running a BBS. 
That's why the existing code is how it is.

I don't want a proof of concept. I want something that is maintainable. 
Adding #ifdef's to the existing code will make the end result way less 
maintainable, either for the standard or the mini use case. By being 
really small, the maintenance cost of a parallel implementation isn't 
very high, certainly much less than trying to maintain a single version 
that can scale to both extremes.


Nicolas

[toc] | [prev] | [next] | [standalone]

#1614941 — Re: [PATCH v2 0/5] minitty: a minimal TTY layer alternative for embedded systems

On Sat, Apr 01, 2017 at 06:21:14PM -0400, Nicolas Pitre wrote:
> Many embedded systems don't need the full TTY layer support. Most of the
> time, the TTY layer is only a conduit for outputting debugging messages
> over a serial port. The TTY layer also implements many features that are
> very unlikely to ever be used in such a setup. There is great potential
> for both code and dynamic memory size reduction on small systems. This is
> what this patch series is achieving.
> 
> The existing TTY code is quite large and complex. Trying to shrink it
> is risky as the potential for breakage is non negligeable, and its
> interchangeable layers impose a lower limit on the code to implement it.
> Therefore, the approach used here consists in the creation of a parallel
> implementation with the very minimal amount of code collapsed together
> that interfaces with existing UART drivers directly and provides TTY-like
> character devices to user space. When the regular TTY layer is disabled,
> then this minitty alternative layer is proposed by Kconfig.
> 
> For more details on the rationale and motivations driving this approach
> please see: https://lkml.org/lkml/2017/3/24/634
> 
> Of course, making it "mini" means there are limitations to what it does:
> 
> - This supports serial ports only. No VT's, no PTY's.
> 
> - The default n_tty line discipline is hardcoded and no other line
>   discipline are supported.
> 
> - The line discipline features are not all implemented. Notably, XON/XOFF
>   is currently not implemented (although this might not require a lot of
>   code to do it if someone were to need it).
> 
> - Hung-up state is not implemented.
> 
> - No error handling on RX bytes other than counting them.
> 
> - Job control is currently not supported (this may change in the future and 
>   be configurable).
> 
> But again, most small embedded systems simply don't need those things.
> 
> This can be used on any architecture of course, but here's some numbers
> using a minimal ARM config.
> 
> When CONFIG_TTY=y, the following files are linked into the kernel:
> 
>    text	   data	    bss	    dec	    hex	filename
>    8796	    128	      0	   8924	   22dc	drivers/tty/n_tty.o
>   11809	    276	      0	  12085	   2f35	drivers/tty/serial/fulltty_serial.o
>    1376	      0	      0	   1376	    560	drivers/tty/tty_buffer.o
>   13571	    172	    132	  13875	   3633	drivers/tty/tty_io.o
>    3072	      0	      0	   3072	    c00	drivers/tty/tty_ioctl.o
>    2457	      2	    120	   2579	    a13	drivers/tty/tty_ldisc.o
>    1328	      0	      0	   1328	    530	drivers/tty/tty_ldsem.o
>     316	      0	      0	    316	    13c	drivers/tty/tty_mutex.o
>    2516	      0	      0	   2516	    9d4	drivers/tty/tty_port.o
>   45241	    578	    252	  46071	   b3f7	(TOTALS)
> 
> When CONFIG_TTY=n and CONFIG_MINITTY_SERIAL=y, the above files are replaced
> by the following:
> 
>    text	   data	    bss	    dec	    hex	filename
>    8063	      8	     64	   8135	   1fc7	drivers/tty/serial/minitty_serial.o
> 
> That's it!  And the runtime buffer usage is much less as well. Future plans
> such as removing runtime baudrate handling for those targets with a known
> fixed baudrate will shrink the code even more.

Thanks for the resend.  I agree with your goal of getting Linux running
on these very tiny chips, I want that to happen too.  I'm traveling at
the moment for the next 2 weeks, but will review it in detail when I get
back.  It's in my queue, don't worry, it's not lost.

Ideally others would review it as well...

thanks,

greg k-h

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web