Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 14 Mar 2012 22:21:39 -0700
From:      Ted Mittelstaedt <tedm@mittelstaedt.us>
To:        Super Bisquit <superbisquit@gmail.com>
Cc:        freebsd-emulation@freebsd.org
Subject:   Re: Fwd: Kernel memory usage
Message-ID:  <4F617C63.9030106@mittelstaedt.us>
In-Reply-To: <CA%2BWntOth%2BQinHiU0GSq=ozbswnqx0v1Gui2D3mrjkZhke3Ounw@mail.gmail.com>
References:  <4F5D48E6.9010802@herveybayaustralia.com.au> <CA%2BWntOt=4P=%2BmdAX3G1s5jQHxt9HFSN6c%2BxTjo9cQAsaSgdJqw@mail.gmail.com> <4F5F2CC5.80608@herveybayaustralia.com.au> <CA%2BWntOv%2B%2BtkAms%2BOQtW-bH=3f7VnUhtA7SA1c8dQYwZho5aX4g@mail.gmail.com> <4F615D09.8030009@mittelstaedt.us> <CA%2BWntOth%2BQinHiU0GSq=ozbswnqx0v1Gui2D3mrjkZhke3Ounw@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
A number of FreeBSD kernel structures are dynamically created at
boot time - based on the amount of ram in the system.  I would guess
if you boot your stripped BSD image on a virtual system with 64Mb of ram 
you wouldn't see the kernel grow to 32MB

It would be interesting to see FreeBSD running on a Smartphone.

Ted

On 3/14/2012 9:03 PM, Super Bisquit wrote:
> On 3/14/12, Ted Mittelstaedt<tedm@mittelstaedt.us>  wrote:
>> What do you regard as a "low memory" machine?
> On real hardware I've used:
> HTC Apache 64/128 ROM/RAM
> Embedded 486 with 5M RAM
> Older tower maxed at 128M
>
> I'd say anything less than 64M RAM for normal hardware, less than 32
> for embedded.
>
> Some systems do not have small memory modules. I have two SunBlade
> 1000s that can be stripped down to 128M.
>
> I'm also aware that the environment limits what the machine can have installed.
>
> There are older systems and embedded devices which run/ran on 16kb of
> RAM.  I'm certain that the oldest electronic led calculators used even
> less memory.
> I digress.
>
>
>
>
>>
>> Ted
>>
>> On 3/13/2012 8:30 AM, Super Bisquit wrote:
>>> ---------- Forwarded message ----------
>>> From: Da Rock<9Phackers@herveybayaustralia.com.au>
>>> Date: Tue, Mar 13, 2012 at 7:17 AM
>>> Subject: Re: Kernel memory usage
>>> To: freebsd-hackers@freebsd.org
>>>
>>>
>>> On 03/13/12 05:40, Super Bisquit wrote:
>>>
>>>> CPU architecture and model have a lot to do with performance.
>>>> You will also get different results if you used qemu in place of
>>>> VirtualBox. Qemu allows you to choose different emulated
>>>> architectures, CPUs, and machine bases. What's the downside? You have
>>>> to use the command line.
>>>> Install qemu and run a series of virtual machines.
>>>> Embedded devices also include Power(PC), ARMv?, Coldfire, et al;
>>>> you're only dealing with i386 and/or the 64 bit extension (AMD64).
>>>> CISC- which does not contain any hardware modification to be a RISC
>>>> replacement- runs fewer instructions than RISC due to the limited
>>>> number of registers.  Take this into consideration every time a
>>>> program runs.
>>>> Everything else also matters on real and emulated systems:
>>>> Is it ide, scsi, sdd, flashdevice for the hard drive?
>>>> What type of RAM?
>>>> Dedicated or shared disk?
>>>>
>>> I'm a little confused by the response, I was interested if someone knew
>>> what determines the size of kernel in memory (or wired); I only considered
>>> the embedded list because they have a greater interest in the memory size
>>> working with so little.
>>>
>>> It is academic as I'm trying to understand the kernel internals, as well
>>> as
>>> understand what works with low memory so I can tune accordingly. I
>>> understand the different CPU instruction sets (roughly), although I would
>>> be interested as to the size of the kernel in each.
>>>
>>> What my question was about was the wired memory size and what makes it
>>> grow
>>> (to put it super simply :) ). I know some growth would be expected, but
>>> this seems obese; how would I find out how much memory a process structure
>>> takes? Or else what am I missing?
>>>
>>> That said I'll have a crack at what you suggest as that follows a whole
>>> new
>>> interesting tangent :) I have used qemu before, but found VBox a bit more
>>> responsive (and, I will admit, easier...)
>>>
>>>
>>>> On 3/11/12, Da
>>>> Rock<9Phackers@**herveybayaustralia.com.au<9Phackers@herveybayaustralia.com.au>>
>>>>    wrote:
>>>>
>>>>> I may be required to move this to embedded, but I am only looking for
>>>>> generalisation.
>>>>>
>>>>> Recently a thread came up on questions regarding memory usage, and a
>>>>> post was made regarding wired memory being nearly all kernel- something
>>>>> I was ready to dispute, but then I thought I'd better make sure.
>>>>>
>>>>> So I tested a few theories first off:
>>>>>
>>>>> 1. Comparing memory usage across machines
>>>>>
>>>>> I checked servers and desktops as well as vm's for memory usage, and I
>>>>> found some interesting results. On a firewall with no apps installed
>>>>> only 35M wired is used, on a desktop up to 700M~ can be used. Even as a
>>>>> dedicated server with a few services used it remains around 35M.
>>>>>
>>>>> Surely this means that the wired memory used is not just kernel? But I
>>>>> held off my assumptions as it was still plausible that the structures
>>>>> used by the kernel could balloon that far, too.
>>>>>
>>>>> 2. Stripped down, lean mean, kernel machine
>>>>>
>>>>> I then (using a vm I was building a kernel for anyway) stripped down a
>>>>> kernel in a VBox VM using le drivers for network to see what could be
>>>>> achieved. This is my kernel conf:
>>>>>
>>>>> include GENERIC
>>>>> ident VPN
>>>>> options IPSEC
>>>>> options IPSEC_DEBUG
>>>>> options IPSEC_NAT_T
>>>>> device crypto
>>>>> device enc
>>>>>
>>>>> # minimise kernel
>>>>> nooptions UFS_GJOURNAL
>>>>> nooptions MD_ROOT
>>>>> nooptions NFSCL
>>>>> nooptions NFSD
>>>>> nooptions NFSLOCKD
>>>>> nooptions NFS_ROOT
>>>>> nooptions MSDOSFS
>>>>> nooptions CD9660
>>>>> nooptions PROCFS
>>>>> nooptions PSEUDOFS
>>>>> nodevice fdc
>>>>> nodevice mvs
>>>>> nodevice siis
>>>>> nodevice ahc
>>>>> nodevice ahd
>>>>> nodevice esp
>>>>> nodevice hptiop
>>>>> nodevice isp
>>>>> nodevice mpt
>>>>> nodevice mps
>>>>> nodevice sym
>>>>> nodevice trm
>>>>> nodevice adv
>>>>> nodevice adw
>>>>> nodevice aic
>>>>> nodevice bt
>>>>> nodevice ses
>>>>> nodevice amr
>>>>> nodevice arcmsr
>>>>> nodevice ciss
>>>>> nodevice dpt
>>>>> nodevice hptmv
>>>>> nodevice hptrr
>>>>> nodevice irr
>>>>> nodevice ips
>>>>> nodevice mly
>>>>> nodevice twa
>>>>> nodevice aac
>>>>> nodevice aacp
>>>>> nodevice ida
>>>>> nodevice mfi
>>>>> nodevice mlx
>>>>> nodevice twe
>>>>> nodevice tws
>>>>> nodevice splash
>>>>> nodevice cbb
>>>>> nodevice pccard
>>>>> nodevice cardbus
>>>>> nodevice uart
>>>>> nodevice ppc
>>>>> nodevice ppbus
>>>>> nodevice lpt
>>>>> nodevice plip
>>>>> nodevice ppi
>>>>> nodevice puc
>>>>> nodevice bxe
>>>>> nodevice de
>>>>> nodevice em
>>>>> nodevice igb
>>>>> nodevice ixgbe
>>>>> nodevice ti
>>>>> nodevice txp
>>>>> nodevice vx
>>>>> nodevice miibus
>>>>> nodevice ae
>>>>> nodevice age
>>>>> nodevice alc
>>>>> nodevice ale
>>>>> nodevice bce
>>>>> nodevice bfe
>>>>> nodevice bge
>>>>> nodevice dc
>>>>> nodevice et
>>>>> nodevice fxp
>>>>> nodevice jme
>>>>> nodevice lge
>>>>> nodevice msk
>>>>> nodevice nfe
>>>>> nodevice nge
>>>>> nodevice pcn
>>>>> nodevice re
>>>>> nodevice rl
>>>>> nodevice sf
>>>>> nodevice sge
>>>>> nodevice sis
>>>>> nodevice sk
>>>>> nodevice ste
>>>>> nodevice stge
>>>>> nodevice tl
>>>>> nodevice tx
>>>>> nodevice vge
>>>>> nodevice vr
>>>>> nodevice wb
>>>>> nodevice xl
>>>>> nodevice cs
>>>>> nodevice ed
>>>>> nodevice ex
>>>>> nodevice ep
>>>>> nodevice fe
>>>>> nodevice sn
>>>>> nodevice xe
>>>>> nodevice wlan
>>>>> nooptions IEEE80211_DEBUG
>>>>> nooptions IEEE80211_AMPDU_AGE
>>>>> nooptions IEEE80211_SUPPORT_MESH
>>>>> nodevice wlan_wep
>>>>> nodevice wlan_ccmp
>>>>> nodevice wlan_tkip
>>>>> nodevice wlan_amrr
>>>>> nodevice an
>>>>> nodevice ath
>>>>> nodevice ath_pci
>>>>> nodevice ath_hal
>>>>> nooptions AH_SUPPORT_AR5416
>>>>> nodevice ath_rate_sample
>>>>> nodevice ipw
>>>>> nodevice iwi
>>>>> nodevice iwn
>>>>> nodevice malo
>>>>> nodevice mwl
>>>>> nodevice ral
>>>>> nodevice wi
>>>>> nodevice wpi
>>>>> nodevice md
>>>>> nooption USB_DEBUG
>>>>> nodevice uhci
>>>>> nodevice ohci
>>>>> nodevice ehci
>>>>> nodevice xhci
>>>>> nodevice usb
>>>>> nodevice uhid
>>>>> nodevice ukbd
>>>>> nodevice ulpt
>>>>> nodevice umass
>>>>> nodevice ums
>>>>> nodevice urio
>>>>> nodevice u3g
>>>>> nodevice uark
>>>>> nodevice ubsa
>>>>> nodevice uftdi
>>>>> nodevice uipaq
>>>>> nodevice uplcom
>>>>> nodevice uslcom
>>>>> nodevice uvisor
>>>>> nodevice uvscom
>>>>> nodevice aue
>>>>> nodevice axe
>>>>> nodevice cdce
>>>>> nodevice cue
>>>>> nodevice kue
>>>>> nodevice rue
>>>>> nodevice udav
>>>>> nodevice rum
>>>>> nodevice run
>>>>> nodevice uath
>>>>> nodevice upgt
>>>>> nodevice ural
>>>>> nodevice urtw
>>>>> nodevice zyd
>>>>> #nodevice firewire
>>>>> nodevice fwe
>>>>> nodevice fwip
>>>>> #nodevice dcons
>>>>> #nodevice dcons_rom
>>>>> nodevice sound
>>>>> nodevice snd_es137x
>>>>> nodevice snd_hda
>>>>> nodevice snd_ich
>>>>> nodevice snd_uaudio
>>>>> nodevice snd_via8233
>>>>>
>>>>> World was also rebuilt as recommended by the handbook. As you can see I
>>>>> was rebuilding for IPSEC (for testing purposes only note). I couldn't
>>>>> remove dcons (not sure why- missing defined references), and that pulled
>>>>> in firewire too.
>>>>>
>>>>> The result was surprising: a 14M kernel became 6.3M, and when running I
>>>>> found it only used 19M used for wired (whoopee!) as opposed to 35M. No
>>>>> services were running per se, only the usual suspects in base:
>>>>>
>>>>> vpn-test# ps ax
>>>>>      PID  TT  STAT      TIME COMMAND
>>>>>        0  ??  DLs    0:00.11 [kernel]
>>>>>        1  ??  ILs    0:00.01 /sbin/init --
>>>>>        2  ??  DL     0:00.00 [crypto]
>>>>>        3  ??  DL     0:00.00 [crypto returns]
>>>>>        4  ??  DL     0:00.00 [sctp_iterator]
>>>>>        5  ??  DL     0:00.00 [xpt_thrd]
>>>>>        6  ??  DL     0:00.10 [pagedaemon]
>>>>>        7  ??  DL     0:00.00 [vmdaemon]
>>>>>        8  ??  DL     0:00.01 [pagezero]
>>>>>        9  ??  DL     0:00.30 [bufdaemon]
>>>>>       10  ??  DL     0:00.00 [audit]
>>>>>       11  ??  RL   589:34.00 [idle]
>>>>>       12  ??  WL     0:38.64 [intr]
>>>>>       13  ??  DL     0:12.21 [geom]
>>>>>       14  ??  DL     0:03.30 [yarrow]
>>>>>       15  ??  DL     0:04.40 [syncer]
>>>>>       16  ??  DL     0:00.63 [vnlru]
>>>>>       17  ??  DL     0:00.53 [softdepflush]
>>>>>      104  ??  Is     0:00.00 adjkerntz -i
>>>>>      582  ??  Is     0:00.00 /sbin/devd
>>>>>      737  ??  Ss     0:00.09 /usr/sbin/syslogd -s
>>>>>      912  ??  Ss     0:02.68 /usr/sbin/ntpd -c /etc/ntp.conf -p
>>>>> /var/run/ntpd.pid
>>>>>      977  ??  Is     0:00.00 /usr/sbin/sshd
>>>>>      984  ??  Ss     0:00.81 sendmail: accepting connections (sendmail)
>>>>>      988  ??  Is     0:00.01 sendmail: Queue runner@00:30:00 for
>>>>> /var/spool/client
>>>>>      994  ??  Ss     0:00.12 /usr/sbin/cron -s
>>>>>     2061  ??  Is     0:00.03 sshd: admin [priv] (sshd)
>>>>>     2064  ??  S      0:00.04 sshd: admin@pts/0 (sshd)
>>>>>     1052  v0  Is     0:00.01 login [pam] (login)
>>>>>     1060  v0  I+     0:00.02 -csh (csh)
>>>>>     1053  v1  Is+    0:00.00 /usr/libexec/getty Pc ttyv1
>>>>>     1054  v2  Is+    0:00.00 /usr/libexec/getty Pc ttyv2
>>>>>     1055  v3  Is+    0:00.00 /usr/libexec/getty Pc ttyv3
>>>>>     1056  v4  Is+    0:00.00 /usr/libexec/getty Pc ttyv4
>>>>>     1057  v5  Is+    0:00.00 /usr/libexec/getty Pc ttyv5
>>>>>     1058  v6  Is+    0:00.00 /usr/libexec/getty Pc ttyv6
>>>>>     1059  v7  Is+    0:00.00 /usr/libexec/getty Pc ttyv7
>>>>>     2065   0  Is     0:00.02 -csh (csh)
>>>>>     2068   0  I      0:00.01 su
>>>>>     2069   0  S      0:00.04 _su (csh)
>>>>>     2414   0  R+     0:00.00 ps ax
>>>>>
>>>>> After some minutes though, the usage went up to 39M. WTF?
>>>>>
>>>>> So I'm now thoroughly confused. Google didn't really show up any real
>>>>> answers either. Aside from discovering the true nature of what was
>>>>> discussed in the posts, my hypothetical theorising is for my own
>>>>> academics as well; and I'm trying to slim down my kernels to see if I
>>>>> can improve performance with low memory systems.
>>>>>
>>>>> Can process structures cause this much ballooning? I find that hard to
>>>>> believe given not much is running here. My only other thought would be
>>>>> pipe or network structures? Anything I'm missing?
>>>>>
>>>>> FWIW, my trimmed down, slim and slender, aerodynamic kernel can boot in
>>>>> seconds as opposed to minutes. Sweet! Although compiling clang took
>>>>> years... and gcc was built as well :/
>>>>>
>>>>> Cheers
>>>>> ______________________________**_________________
>>>>> freebsd-hackers@freebsd.org mailing list
>>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers<http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>;
>>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@**
>>>>> freebsd.org<freebsd-hackers-unsubscribe@freebsd.org>"
>>>>>
>>>>>    ______________________________**_________________
>>>> freebsd-hackers@freebsd.org mailing list
>>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers<http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>;
>>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@**
>>>> freebsd.org<freebsd-hackers-unsubscribe@freebsd.org>"
>>>>
>>>
>>> ______________________________**_________________
>>> freebsd-hackers@freebsd.org mailing list
>>> http://lists.freebsd.org/**mailman/listinfo/freebsd-**hackers<http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>;
>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>>>
>>> I'm fowarding this thread in the event the individual, "da Rock" will be
>>> able to receive more help.
>>> _______________________________________________
>>> freebsd-emulation@freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-emulation
>>> To unsubscribe, send any mail to
>>> "freebsd-emulation-unsubscribe@freebsd.org"
>>>
>>>
>>> -----
>>> No virus found in this message.
>>> Checked by AVG - www.avg.com
>>> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: 03/14/12
>>
>>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1913 / Virus Database: 2114/4871 - Release Date: 03/14/12




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F617C63.9030106>