Re: [PREVIEW] bsdconfig(8)
On Mar 6, 2012, at 1:10 AM, Alexander Best wrote: > great work. a few questions or rather suggestions: > [snip] > 2) the highlighted first letters suggest that these are shortcuts. they work > great for the actual menu items, but for "" and "", > pressing O and E doesn't work. in fact E is already taken by "Startup". It's since been discovered that --visit-items achieves the desired behavior (and is accepted by Xdialog(1) so seems safe to use unconditionally). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: will 9.2 be called 'diehard'? or maybe Naktomi?
"Energizer Bunny" is more threatening. On 3/13/12, Julian Elischer wrote: > > > http://modcult.org/read/2008/2/20/nakatomi-socrates-bsd-9-2 > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: hack.So: could not read symbols
On Tue, Mar 13, 2012 at 12:23 AM, Ryan Stone wrote: > 2012/3/12 Fernando Apesteguía : >> I'm using 9.0-RELEASE. >> >> I downloaded the snapshot "9.0-CURRENT-201012" and tried to build it's >> kernel but I get this error: >> >> hack.So: could not read symbols: File in wrong format >> >> file reports this: >> >> ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), dynamically >> linked, not stripped >> >> I compared this file with the same file generated during the >> compilation of the 9.0-RELEASE GENERIC kernel and they are identical. >> >> What's the problem here? > > I saw a similar issue trying to build a stable/8 kernel on > 9.0-RELEASE. Doing a make kernel-toolchain before make buildkernel > fixed the issue. Yep, that was it. Thank you! I was able to compile the kernel but it can not mount root fs. It reports error 19 (ENODEV). Weird. It tries to mount ada0p2 that is properly detected if I type "?" when I get the mount prompt. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
will 9.2 be called 'diehard'? or maybe Naktomi?
http://modcult.org/read/2008/2/20/nakatomi-socrates-bsd-9-2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [vfs] buf_daemon() slows down write() severely on low-speed CPU
On 12 March 2012 11:19, Konstantin Belousov wrote: > The 32MB is indeed around the lowest amount of memory where recent > FreeBSD can make an illusion of being useful. I am not sure how much > should the system be tuned by default for such configuration. Some -new- embedded wifi hardware is shipping with 16MB of RAM. Just saying, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [vfs] buf_daemon() slows down write() severely on low-speed CPU
On Mon, Mar 12, 2012 at 7:19 PM, Konstantin Belousov
wrote:
> On Mon, Mar 12, 2012 at 04:00:58PM +0100, Svatopluk Kraus wrote:
>> Hi,
>>
>> I have solved a following problem. If a big file (according to
>> 'hidirtybuffers') is being written, the write speed is very poor.
>>
>> It's observed on system with elan 486 and 32MB RAM (i.e., low speed
>> CPU and not too much memory) running FreeBSD-9.
>>
>> Analysis: A file is being written. All or almost all dirty buffers
>> belong to the file. The file vnode is almost all time locked by
>> writing process. The buf_daemon() can not flush any dirty buffer as a
>> chance to acquire the file vnode lock is very low. A number of dirty
>> buffers grows up very slow and with each new dirty buffer slower,
>> because buf_daemon() eats more and more CPU time by looping on dirty
>> buffers queue (with very low or no effect).
>>
>> This slowing down effect is started by buf_daemon() itself, when
>> 'numdirtybuffers' reaches 'lodirtybuffers' threshold and buf_daemon()
>> is waked up by own timeout. The timeout fires at 'hz' period, but
>> starts to fire at 'hz/10' immediately as buf_daemon() fails to reach
>> 'lodirtybuffers' threshold. When 'numdirtybuffers' (now slowly)
>> reaches ((lodirtybuffers + hidirtybuffers) / 2) threshold, the
>> buf_daemon() can be waked up within bdwrite() too and it's much worse.
>> Finally and with very slow speed, the 'hidirtybuffers' or
>> 'dirtybufthresh' is reached, the dirty buffers are flushed, and
>> everything starts from beginning...
> Note that for some time, bufdaemon work is distributed among bufdaemon
> thread itself and any thread that fails to allocate a buffer, esp.
> a thread that owns vnode lock and covers long queue of dirty buffers.
However, the problem starts when numdirtybuffers reaches
lodirtybuffers count and ends around hidirtybuffers count. There are
still plenty of free buffers in system.
>>
>> On the system, a buffer size is 512 bytes and the default
>> thresholds are following:
>>
>> vfs.hidirtybuffers = 134
>> vfs.lodirtybuffers = 67
>> vfs.dirtybufthresh = 120
>>
>> For example, a 2MB file is copied into flash disk in about 3
>> minutes and 15 second. If dirtybufthresh is set to 40, the copy time
>> is about 20 seconds.
>>
>> My solution is a mix of three things:
>> 1. Suppresion of buf_daemon() wakeup by setting bd_request to 1 in
>> the main buf_daemon() loop.
> I cannot understand this. Please provide a patch that shows what do
> you mean there.
>
curthread->td_pflags |= TDP_NORUNNINGBUF | TDP_BUFNEED;
mtx_lock(&bdlock);
for (;;) {
- bd_request = 0;
+ bd_request = 1;
mtx_unlock(&bdlock);
I read description of bd_request variable. However, bd_request should
serve as an indicator that buf_daemon() is in sleep. I.e., the
following paradigma should be used:
mtx_lock(&bdlock);
bd_request = 0;/* now, it's only time when wakeup() will be meaningful */
sleep(&bd_request, ..., hz/10);
bd_request = 1; /* in case of timeout, we must set it (bd_wakeup()
already set it) */
mtx_unlock(&bdlock);
My patch follows the paradigma. What happens without the patch in
described problem: buf_daemon() fails in its job and goes to sleep
with hz/10 period. It supposes that next early wakeup will do nothing
too. bd_request is untouched but buf_daemon() doesn't know if its last
wakeup was made by bd_wakeup() or by timeout. So, bd_request could be
0 and buf_daemon() can be waked up before hz/10 just by bd_wakeup().
Moreover, setting bd_request to 0 when buf_daemon() is not in sleep
can cause time consuming and useless wakeup() calls without effect.
>> 2. Increment of buf_daemon() fast timeout from hz/10 to hz/4.
>> 3. Tuning dirtybufthresh to (((lodirtybuffers + hidirtybuffers) /
>> 2) - 15) magic.
> Even hz / 10 is awfully long time on modern hardware.
> The dirtybufthresh is already the sysctl that you can change.
Yes, I noted low-speed CPU. Don't forget that even if buf_daemon()
sleeps for hz/4 period (and this is expected to be rare case),
dirtybufthresh still works and helps. And I don't push the changes
(except bd_request one (a little)). I'm just sharing my experience.
> The 32MB is indeed around the lowest amount of memory where recent
> FreeBSD can make an illusion of being useful. I am not sure how much
> should the system be tuned by default for such configuration.
Even recent FreeBSD on this configuration is useful pretty much. Of
course, file operations are not main concern ... IMHO, it's always
good to know how the system works (and its parts) in various
configurations.
>>
>> The mention copy time is about 30 seconds now.
>>
>> The described problem is just for information to anyone who can be
>> interested in. Comments are welcome. However, the bd_request thing is
>> more general.
>>
>> bd_request (despite its description) should be 0 only when
>> buf_daemon() is in sleep(). Otherwise, wakeup() o
Re: Kernel memory usage
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<9phack...@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
