Re: Time to bump default VM_SWZONE_SIZE_MAX?
Colin Percival cperc...@freebsd.org writes: If I'm understanding things correctly, the maxswzone value -- set by the kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default -- should be approximately 9 MiB per GiB of swap space. Far less, in fact. As mentioned in loader(8), the default 32 MB limit is enough for slightly more than 7 GB of swap space - assuming 100% efficient use of swblocks. The man page recommends not using more than half the theoretical limit, or, with 16 pages per swblock, 1 maxswzone x s --- x --- 2 16 where s = 276 on 32-bit systems and 288 on 64-bit systems. The current default for VM_SWZONE_SIZE_MAX was set in August 2002 to 32 MiB; meaning that anyone who wants to use more than ~ 3.5 GB of swap space ought to set kern.maxswzone in /boot/loader.conf. Is it time to increase this default on amd64? (I understand that keeping the value low on i386 is important due to KVA limitations, but amd64 has far more address space available...) There is no reason to keep this limit at all. The algorithm used to size the zone is physpages / 2 * sizeof(struct swblock) or maxswzone, whichever is smaller where maxswzone == VM_SWZONE_SIZE_MAX unless kern.maxswzone was set in loader.conf. On amd64, the cutoff point is slightly below 1 GB of physical memory (233,016 4,096-byte pages), so the limit doesn't help machines that actually need to conserve memory, and it hurts machines that have plenty of it and therefore also plenty of swap (assuming the user followed the old twice the amount of RAM rule of thumb). DES -- Dag-Erling Smørgrav - d...@des.no Index: sys/boot/common/loader.8 === --- sys/boot/common/loader.8 (revision 238711) +++ sys/boot/common/loader.8 (working copy) @@ -615,14 +615,16 @@ Limits the amount of KVM to be used to hold swap meta information, which directly governs the maximum amount of swap the system can support. -This value is specified in bytes of KVA space -and defaults to 32MBytes on i386 and amd64. +This value is specified in bytes of KVA space. +If no value is provided, the system allocates +enough memory to handle an amount of swap +that corresponds to eight times the amount of +physical memory present in the system. +.Pp Care should be taken to not reduce this value such that the actual -amount of configured swap exceeds 1/2 the -kernel-supported swap. -The default of 32MB allows -the kernel to support a maximum of ~7GB of swap. +amount of configured swap exceeds the amount +supported by the kernel. Only change this parameter if you need to greatly extend the KVM reservation for other resources such as the Index: sys/amd64/include/param.h === --- sys/amd64/include/param.h (revision 238711) +++ sys/amd64/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Mach derived conversion macros */ #define round_page(x) unsigned long)(x)) + PAGE_MASK) ~(PAGE_MASK)) Index: sys/i386/include/param.h === --- sys/i386/include/param.h (revision 238711) +++ sys/i386/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Ceiling on size of buffer cache (really only effects write queueing, * the VM page cache is not effected), can be changed via * the kern.maxbcache /boot/loader.conf variable. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: swp_pager_meta_build DoS printf
Sergey Kandaurov pluk...@gmail.com writes:
What about this patch? It enables to ratelimit the printf.
I have a different patch that just prints one message when swzone is
exhausted and another when more space becomes available. However, we
might want to combine the two, so that it periodically prints a message
as long as swzone is exhausted.
DES
--
Dag-Erling Smørgrav - d...@des.no
Index: sys/vm/swap_pager.c
===
--- sys/vm/swap_pager.c (revision 238711)
+++ sys/vm/swap_pager.c (working copy)
@@ -1804,6 +1804,7 @@
static void
swp_pager_meta_build(vm_object_t object, vm_pindex_t pindex, daddr_t swapblk)
{
+ static volatile int exhausted;
struct swblock *swap;
struct swblock **pswap;
int idx;
@@ -1847,7 +1848,9 @@
mtx_unlock(swhash_mtx);
VM_OBJECT_UNLOCK(object);
if (uma_zone_exhausted(swap_zone)) {
-printf(swap zone exhausted, increase kern.maxswzone\n);
+if (atomic_cmpset_rel_int(exhausted, 0, 1))
+ printf(swap zone exhausted,
+ increase kern.maxswzone\n);
vm_pageout_oom(VM_OOM_SWAPZ);
pause(swzonex, 10);
} else
@@ -1856,6 +1859,9 @@
goto retry;
}
+ if (atomic_cmpset_rel_int(exhausted, 1, 0))
+ printf(swap zone ok\n);
+
swap-swb_hnext = NULL;
swap-swb_object = object;
swap-swb_index = pindex ~(vm_pindex_t)SWAP_META_MASK;
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time to bump default VM_SWZONE_SIZE_MAX?
Slightly better patch (improved documentation) DES -- Dag-Erling Smørgrav - d...@des.no Index: sys/boot/common/loader.8 === --- sys/boot/common/loader.8 (revision 239239) +++ sys/boot/common/loader.8 (working copy) @@ -613,17 +613,26 @@ for details. .It Va kern.maxswzone Limits the amount of KVM to be used to hold swap -meta information, which directly governs the -maximum amount of swap the system can support. -This value is specified in bytes of KVA space -and defaults to 32MBytes on i386 and amd64. -Care should be taken -to not reduce this value such that the actual -amount of configured swap exceeds 1/2 the -kernel-supported swap. -The default of 32MB allows -the kernel to support a maximum of ~7GB of swap. -Only change +metadata, which directly governs the +maximum amount of swap the system can support, +at the rate of approximately 200 MB of swap space +per 1 MB of metadata. +This value is specified in bytes of KVA space. +If no value is provided, the system allocates +enough memory to handle an amount of swap +that corresponds to eight times the amount of +physical memory present in the system. +.Pp +Note that swap metadata can be fragmented, +which means that the system can run out of +space before it reaches the theoretical limit. +Therefore, care should be taken to not configure +more swap than approximately half of the +theoretical maximum. +.Pp +Running out of space for swap metadata can leave +the system in an unrecoverable state. +Therefore, you should only change this parameter if you need to greatly extend the KVM reservation for other resources such as the buffer cache or Index: sys/amd64/include/param.h === --- sys/amd64/include/param.h (revision 239239) +++ sys/amd64/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Mach derived conversion macros */ #define round_page(x) unsigned long)(x)) + PAGE_MASK) ~(PAGE_MASK)) Index: sys/i386/include/param.h === --- sys/i386/include/param.h (revision 239239) +++ sys/i386/include/param.h (working copy) @@ -123,14 +123,6 @@ #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ /* - * Ceiling on amount of swblock kva space, can be changed via - * the kern.maxswzone /boot/loader.conf variable. - */ -#ifndef VM_SWZONE_SIZE_MAX -#define VM_SWZONE_SIZE_MAX (32 * 1024 * 1024) -#endif - -/* * Ceiling on size of buffer cache (really only effects write queueing, * the VM page cache is not effected), can be changed via * the kern.maxbcache /boot/loader.conf variable. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Soekris net4801 sees no disk devices with -CURRENT
On Mon, Aug 13, 2012 at 11:30:06PM +0200, Pierre DAVID wrote: On Sun, Aug 12, 2012 at 05:49:24PM +0200, Paul Schenkeveld wrote: Hi, I am trying to build a NanoBSD image for Soekris net4801 with a recent -CURRENT. The kernel boots fine but when it comes to mounting the root filesystem, it cannot find the flash disk anymore. Bios is up to date (1.33). Hello, I'm trying to resurrect my old net4801 and update it with -CURRENT (old version was a 8-CURRENT), and I do not succeed to get kernel output via the RS-232 port. Kernel goes mute just after being loaded. Could you send me your NanoBSD kernel configuration file? Pierre Below is my kernel config. You also have to use boot0sio and create a file called /boot.config containing -h so the boot loader knows that you want to use a serial console. Usually NanoBSD does that for you if you include customize_cmd cust_comconsole in your NanoBSD config file and leave NANO_BOOTLOADER set to its default of boot/boot0sio. # from GENERIC cpu I586_CPU ident NET4801 options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options INCLUDE_CONFIG_FILE # Include this file in kernel device apic# I/O APIC device cpufreq device acpi device pci device ahci# AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA device siis# SiliconImage SiI3124/SiI3132/SiI3531 SATA device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) device pass# Passthrough device (direct ATA/SCSI access) device ctl # CAM Target Layer device pmtimer device uart# Generic UART driver device miibus # MII bus support device sis # Silicon Integrated Systems SiS 900/SiS 7016 device loop# Network loopback device random # Entropy device device ether # Ethernet support device vlan# 802.1Q VLAN support device tun # Packet tunnel. device md # Memory disks device gif # IPv6 and IPv4 tunneling device bpf # Berkeley packet filter options USB_DEBUG # enable debug msgs device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da # local additions makeoptions MODULES_OVERRIDE= options CPU_GEODE options CPU_SOEKRIS device atadisk # ATA disk drives I have tried with and without the device atadisk line but my compact flash is never seen by the kernel. Kind regards, Paul Schenkeveld ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time to bump default VM_SWZONE_SIZE_MAX?
On 08/13/12 14:23, Peter Jeremy wrote: On 2012-Aug-12 15:44:07 -0700, Colin Percival cperc...@freebsd.org wrote: If I'm understanding things correctly, the maxswzone value -- set by the kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default -- should be approximately 9 MiB per GiB of swap space. I'm not sure how you got that value. By default, struct swblock is 288 bytes (280 bytes on 32-bit archs) and can store up to 32 pages of swap (the comment in vm/swap_pager.c:swap_pager_swap_init() is wrong). For x86, this is 2.25 MiB per GiB (best case). I got that value from a previous mailing list discussion -- I think it was based on the (incorrect) value of 16 pages per swblock and not exceeding 50% swblock utilization. Realistically, I'd say that the default VM_SWZONE_SIZE_MAX can handle about 9GB swap (at least, that was my experience). The 50% utilization rule of thumb would make it 7 GB, but yes, same order of magnitude. BTW, if you plan on allocating lots of swap, be aware that each swap device is limited to 32GiB - see vm/swap_pager.c:swaponsomething(). Yes, noted. I'm not actually using lots of swap myself, but I was writing code for EC2 instances to set up reasonable amounts of swap at boot time, and I don't want to accidentally autoconfigure more swap than FreeBSD can safely use. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic: page fault
http://privatepaste.com/147286442b ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geom mirror now rebuilding on every reboot?
On Mon, 2012-08-06 at 08:34 -0700, Maksim Yevmenkin wrote: Michael, Something in -current and recently MFC'd to -stable is causing all of my gmirror drives to rebuild on reboot :-( Being remote and these being production machines, I suspect SVN r237929 and r237930 in -current and SVN r238500 to -stable but haven't yet been able to prove it. Is anyone else seeing this? yes, i've seem something similar only much, much worse. one of our production systems completely kept loosing its gmirror volumes on every reboot. it looked like gmirror metadata were completely corrupted. rebuilding mirrors and reverting back to previous kernel seemed to work. someone else is tracking it down. Have they managed to track this down to a commit or range of commits yet? Thanks, Gavin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Speaking of ship blockers for 9....
Gleb Smirnoff wrote: I Jul 22 08:54:25 brane kernel: pf: state key linking mismatch! dir=OUT, if= I tun0, stored af=2, a0: 10.0.2.220:60985, a1: 192.41.162.30:53, proto=17, I found af=2, a0: 41.154.2.53:1701, a1: 41.133.165.161:59051, proto=17. Let me give you link to my branch of pf: http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006643.html http://lists.freebsd.org/pipermail/freebsd-pf/2012-June/006662.html In that branch the code that puts the reverse pointer on state keys, as well as the m_addr_changed() function and the pf_compare_state_keys() had been cut away. So, this exact bug definitely can't be reproduced there. However, others may hide in :) Let me encourage you to try and test my branch (instructions in URLs above). I do see much better performance, however, I'm seeing this panic after about 23 minutes (the slightly higher uptime was a result of a manual fsck). This system is not particularly loaded. It's a UP Pentium-m which is our office gateway. I can give you access to inspect if you like. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor write, page not present instruction pointer = 0x20:0xc046f8f4 stack pointer = 0x28:0xeb7b7bd8 frame pointer = 0x28:0xeb7b7bec code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 4 (pf purge) trap number = 12 panic: page fault KDB: stack backtrace: db_trace_self_wrapper(c0819c2b,eb7b7a78,c05d5829,c0816ff2,c08acca0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c0816ff2,c08acca0,c07f2736,eb7b7a84,eb7b7a84,...) at kdb_backtrace+0x29 panic(c07f2736,c0845a85,c559fd68,1,1,...) at panic+0xc9 trap_fatal(0,c60c826c,c610b31c,c610ac44,8,...) at trap_fatal+0x353 trap_pfault(eb7b7b18,c05c0a2d,c0ecc500,c0ecc608,c54ec000,...) at trap_pfault+0xd9 trap(eb7b7b98) at trap+0x418 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xc046f8f4, esp = 0xeb7b7bd8, ebp = 0xeb7b7bec --- pf_state_key_detach(eb7b7c18,c046af2a,502a6f69,0,8000,...) at pf_state_key_detach+0x74 pf_detach_state(c64d5d00,0,8000,0,c559fbc0,...) at pf_detach_state+0x1c6 pf_unlink_state(c64d5d00,1,0,0,c0870398,...) at pf_unlink_state+0x1c5 pf_purge_expired_states(c08947c0,0,0,c07eadbf,64,...) at pf_purge_expired_states+0xe6 pf_purge_thread(0,eb7b7d08,0,c54ec000,0,...) at pf_purge_thread+0x14f fork_exit(c0471b60,0,eb7b7d08) at fork_exit+0xa2 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xeb7b7d40, ebp = 0 --- Uptime: 57m29s Physical memory: 2038 MB Dumping 189 MB: 174 158 142 126 110 94 78 62 46 30 14 (kgdb) bt #0 doadump (textdump=1) at pcpu.h:249 #1 0xc05d563a in kern_reboot (howto=260) at /usr/src.pflock/sys/kern/kern_shutdown.c:449 #2 0xc05d5888 in panic (fmt=Variable fmt is not available.) at /usr/src.pflock/sys/kern/kern_shutdown.c:637 #3 0xc07b8b23 in trap_fatal (frame=0xeb7b7b98, eva=0) at /usr/src.pflock/sys/i386/i386/trap.c:1028 #4 0xc07b8c09 in trap_pfault (frame=0xeb7b7b98, usermode=0, eva=0) at /usr/src.pflock/sys/i386/i386/trap.c:881 #5 0xc07b9a58 in trap (frame=dwarf2_read_address: Corrupted DWARF expression.) at /usr/src.pflock/sys/i386/i386/trap.c:552 #6 0xc07a579c in calltrap () at /usr/src.pflock/sys/i386/i386/exception.s:169 #7 0xc046f8f4 in pf_state_key_detach (s=0xc64d5d00, idx=1) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1040 #8 0xc04713f6 in pf_detach_state (s=0xc64d5d00) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1006 #9 0xc0471975 in pf_unlink_state (s=0xc64d5d00, flags=Variable flags is not available.) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1520 #10 0xc0471a96 in pf_purge_expired_states (maxcheck=148) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1573 #11 0xc0471caf in pf_purge_thread (v=0x0) at /usr/src.pflock/sys/contrib/pf/net/pf.c:1371 #12 0xc05a5af2 in fork_exit (callout=0xc0471b60 pf_purge_thread, arg=0x0, frame=0xeb7b7d08) at /usr/src.pflock/sys/kern/kern_fork.c:995 #13 0xc07a5814 in fork_trampoline () at /usr/src.pflock/sys/i386/i386/exception.s:276 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
zfsloader failure with r239244
Hi, I just upgraded my system from r238261 to r239244 and was unable to boot one of my zfs root systems. I had to recover using the zfsloader.old that is kept in /boot. The messages from zfsloader were: ZFS: can't find pool by guid ZFS: can't find pool by guid can't load 'kernel' followed by a loader prompt. My loader.conf has: vfs.root.mountfrom=zfs:zroot as well as other settings. I suspect this may be related to the fact that my zfs root is formatted using a legacy on-disk format. Specifically, it is version 14 and for the record it's on an MBR partition. This system also has two other pools, one which is version 28 and another which is the latest zpool version (I think? No version number is shown in zpool list -o all, only a -). I've avoided zpool upgrading this pool because I'm a little nervous about updating zfsboot via dd. I didn't see the issue on another zfs root system which is using GPT and the latest zpool version and was upgraded from/to the same versions. Any ideas if this is a bug or something wrong with my system would be appreciated. Thanks, Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: zfsloader failure with r239244
On 14.08.2012 21:03, Steve Wills wrote: Any ideas if this is a bug or something wrong with my system would be appreciated. Can you boot with serial console and show what show the `lsdev` command in the loader? And from the running system the output of `gpart show` and `zpool status`. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
Hello, Current.
I'm using Soekris net5501 (AMD Geode 500Mhz, 512MiB of RAM) as
all-in-one home router: it connects my network to ISP via PPPoE
(40Mbit shaped channel, ng0, over 100Mbit ethernet, interface vr1) and acts as
AP for my
WiFi (Atheros card). It connected to my wired home network with gigabit Intel
card
(em0, old PCI one).
One of servers in my network acts as storage and torrent box in same
time. It is connected to wire network (gigabit one).
And I found strange thing: when torrents are active (40Mbit up and
down, from em0 to ng0 over vr1 with firewall and NAT) router could
pass only about 0.1MiB/s of trafic from internal (gigabit) network
into WiFi. Yes, 0.1MiB/s. When torrents are not active it could
provide from 1.5 to 2.2MiB/s, depending on time of day (and state of
environment), so in this case radio channel is limiting factor.
Answer looks trivial: router CPU is bottleneck. But here is one additional
detail: `top' never shows less than 50% of idle when torrents are
active. And `idle' time with torrents traffic is ALWAYS is higher than
without them, but with WiFi traffic.
Here is typical top-5 when torrents AND WiFi is active (WiFi speed
is terrible):
PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND
10 root 155 ki31 0K 8K RUN 3:29 75.20% idle
11 root -72- 0K80K WAIT 2:33 12.50% intr{swi1: netisr 0}
11 root -92- 0K80K WAIT 0:39 6.40% intr{irq15: ath0
ata1}
14 root -16- 0K 8K -0:12 5.76% yarrow
0 root -920 0K72K -0:10 1.17% kernel{ath0 taskq}
Here is typical top-5 when ONLY WiFi is active (please, note: idle is
less than in previous case!):
PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND
10 root 155 ki31 0K 8K RUN 3:12 38.57% idle
11 root -92- 0K80K WAIT 0:31 34.67% intr{irq15: ath0
ata1}
11 root -72- 0K80K WAIT 2:12 13.67% intr{swi1: netisr 0}
0 root -920 0K72K -0:08 7.47% kernel{ath0 taskq}
14 root -16- 0K 8K -0:10 4.69% yarrow
Here is typical top-5 only with torrents:
PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND
10 root 155 ki31 0K 8K RUN 3:47 82.67% idle
11 root -72- 0K80K WAIT 3:00 10.60% intr{swi1: netisr 0}
14 root -16- 0K 8K -0:13 5.18% yarrow
11 root -92- 0K80K WAIT 0:40 0.78% intr{irq15: ath0
ata1}
1870 root 200 10684K 2268K RUN 0:02 0.59% top
And here is typical top-5 with no traffic
PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND
10 root 155 ki31 0K 8K RUN 4:36 98.58% idle
11 root -72- 0K80K WAIT 3:22 5.08% intr{swi1: netisr 0}
14 root -16- 0K 8K -0:14 0.78% yarrow
11 root -92- 0K80K WAIT 0:41 0.68% intr{irq15: ath0
ata1}
1870 root 200 10684K 2268K RUN 0:02 0.29% top
I'm wonder, why adding torrent traffic slows down WiFi transfer BUT
gives much more idle time than WiFi transfer alone?
I'm using CURRENT r239228 with SCHED_ULE.
--
// Black Lion AKA Lev Serebryakov l...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Strange behavior of r239228 on i386 -- looks like livelocks
Hello, Current. It looks like I've got live lock on my router. It acts as router, but physical console (serial one) and ssh connection are stalled and don't react on keypresses. After two or three minutes everything unfreeze, then freeze again... After unfreeze here are messages from nut that connection with UPS is lost (UPS is connected to other host in network) and re-established. I don't understand how to debug such situation :) uname -a is: FreeBSD gateway.home.serebryakov.spb.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #1 r239228: Mon Aug 13 13:07:52 MSK 2012 r...@vmware-c-32.home.serebryakov.spb.ru:/usr/obj/nanobsd.gateway-net5501/data/src/sys/NET5501 i386 Scheduler is ULE. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Strange behavior of r239228 on i386 -- looks like livelocks
Hello, Lev. You wrote 15 августа 2012 г., 0:51:03: LS It looks like I've got live lock on my router. It acts as router, LS but physical console (serial one) and ssh connection are stalled and LS don't react on keypresses. After two or three minutes everything LS unfreeze, then freeze again... named (BIND) could not resolve names (for other network clients) in these moments. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
Hi, Would you be willing to compile a kernel with KTR so you can capture some KTR scheduler dumps? That way the scheduler peeps can feed this into schedgraph.py (and you can too!) to figure out what's going on. Maybe things aren't being scheduled correctly and the added latency is killing performance? Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
On 08/14/2012 12:20 PM, Adrian Chadd wrote: Hi, Would you be willing to compile a kernel with KTR so you can capture some KTR scheduler dumps? That way the scheduler peeps can feed this into schedgraph.py (and you can too!) to figure out what's going on. Maybe things aren't being scheduled correctly and the added latency is killing performance? You might also try switching to SCHED_ULE to see if it helps. Although, in the last few months as mav has been converging the 2 I've started to see the same problems I saw on my desktop systems previously re-appear even using ULE. For example, if I'm watching an AVI with VLC and start doing anything that generates a lot of interrupts (like moving large quantities of data from one disk to another) the video and sound start to skip. Also, various other desktop features (like menus, window switching, etc.) start to take measurable time to happen, sometimes seconds. ... and lest you think this is just a desktop problem, I've seen the same scenario on 8.x systems used as web servers. With ULE they were frequently getting into peak load situations that created what I called mini thundering herd problems where they could never quite get caught up. Whereas switching to 4BSD the same servers got into high-load situations less often, and they recovered on their own in minutes. Doug ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
(i)frame based sites cause horrible performence in firefox 14.0.1
Sites that are based on frames or iframes (such as google mail and most of google's non-search services) kill the performance of www/firefox [firefox-14.0.1_1,1] (last updated yesterday on a 9.1 built at the same time) here is the uname: FreeBSD XXX 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #2: Thu Aug 9 15:54:37 EDT 2012 root@XXX:/usr/obj/usr/src/sys/GENERIC i386 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
