Date: Wed, 14 Mar 2012 20:07:53 -0700 From: Ted Mittelstaedt <tedm@mittelstaedt.us> To: freebsd-emulation@freebsd.org Subject: Re: Fwd: Kernel memory usage Message-ID: <4F615D09.8030009@mittelstaedt.us> In-Reply-To: <CA%2BWntOv%2B%2BtkAms%2BOQtW-bH=3f7VnUhtA7SA1c8dQYwZho5aX4g@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>
next in thread | previous in thread | raw e-mail | index | archive | help
What do you regard as a "low memory" machine? 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F615D09.8030009>