Re: PQ_LAUNDRY: unexpected behaviour
email freebsd-wireless with the wifi details. i know our iwm driver gets antenna configs wrong sometimes and that can cause issues. -a On 6 January 2017 at 11:07, Jonathan Anderson wrote: > On 6 Jan 2017, at 13:53, Pete Wright wrote: >> >> >> i've been having the same problems with iwm too (failing to load firmware >> on boot). my trick has been to either boot into an old kernel where iwm was >> mostly usable. also i've commented out the line enabling wlan0 in my >> rc.conf then uncommented it after boot and manually running "service netif >> start" to bring up iwm. that method works most of the time... >> -pete > > > I am able to load iwm (iwm7265fw), but there are some networks that I just > can't connect to (INIT -> INIT, swscan_cancel_scan, repeat). Attaching to an > iPhone hotspot is one example of a not-entirely-helpful network, but there > is other, more typical infrastructure that gives trouble too. There is an > iwm8xxx in the room that seems to work fine, however... I do not meddle in > the affairs of wi-fi, for it is subtle and quick to anger. :) > > > Jon > -- > Jonathan Anderson > jonat...@freebsd.org > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 6 Jan 2017, at 14:26, Matthew Macy wrote: Thanks. Pete already filed that as part of #108. With luck markj@ will have that fixed this weekend. -M Fantastic, I'll subscribe to that issue. Cheers, Jon -- jonathan.ander...@ieee.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 6 Jan 2017, at 14:06, Matthew Macy wrote: kernel cores tend to be large (all of wired memory after all) and unless I have exactly the same kernel as you with the same sources at the same changeset, not useful. A backtrace is a good place to start. kgdb /boot/kernel/kernel /var/crash/vmcore.last % bt -M Ok, here we are: #0 doadump (textdump=0) at pcpu.h:222 #1 0x82a445e7 in vt_kms_postswitch (arg=) at /usr/home/jon/freebsd/graphics/sys/modules/drm/drm/../../../dev/drm/linux_fb.c:82 #2 0x808de76b in vt_window_switch (vw=0x81760ea8) at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:540 #3 0x808dc280 in vtterm_cngrab (tm=) at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:1465 #4 0x809f3e02 in cngrab () at /usr/home/jon/freebsd/graphics/sys/kern/kern_cons.c:368 #5 0x80a4d27a in vpanic (fmt=0x80ff218f "Assertion %s failed at %s:%d", ap=0xfe0233e6f5f0) at /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:765 #6 0x80a4d166 in kassert_panic (fmt=) at /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:669 #7 0x80d2b93c in vm_fault_hold (map=0xf8010c9aa000, vaddr=34369822720, fault_type=, fault_flags=0, m_hold=0x0) at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:389 #8 0x80d2a1b8 in vm_fault (map=0xf8010c9aa000, vaddr=optimized out>, fault_type=2 '\002', fault_flags=) at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:474 #9 0x80ebb412 in trap_pfault (frame=0xfe0233e6f9c0, usermode=1) at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:708 #10 0x80ebaba2 in trap (frame=0xfe0233e6f9c0) at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:326 #11 0x80e9b181 in calltrap () at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/exception.S:236 #12 0x0008022a3876 in ?? () It looks like the other core files have the same backtrace. Please let me know if any other details would help... Jon -- jonathan.ander...@ieee.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 6 Jan 2017, at 12:48, Pete Wright wrote: On 1/6/17 9:14 AM, Matthew Macy wrote: I just did the merge and it's using a relatively untested new KPI so regressions aren't too surprising I'm afraid. #96 is more or less content free in terms of providing useful information. Getting a core + backtrace would be a lot more helpful. See the repo's wiki for details on improving your odds of getting a core. I have found the following has enabled me to catch kernel panic's pretty reliably on the drm-next branch when i have the i915kms module loaded: dev.drm.skip_ddb=1 Excellent: I turned that on and got a core, then got another core while tar'ing up the first core. :) The machine in question is currently not connected to any network (iwm is being a bit unhappy), but once it is, where can I put the tarball? Jon -- jonathan.ander...@ieee.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
Thanks. Pete already filed that as part of #108. With luck markj@ will have that fixed this weekend. -M On Fri, 06 Jan 2017 11:24:00 -0800 Jonathan Anderson wrote > On 6 Jan 2017, at 14:06, Matthew Macy wrote: > > > kernel cores tend to be large (all of wired memory after all) and > > unless I have exactly the same kernel as you with the same sources at > > the same changeset, not useful. A backtrace is a good place to start. > >> kgdb /boot/kernel/kernel /var/crash/vmcore.last > > % bt > > > > -M > > Ok, here we are: > > #0 doadump (textdump=0) at pcpu.h:222 > #1 0x82a445e7 in vt_kms_postswitch (arg=) > at > /usr/home/jon/freebsd/graphics/sys/modules/drm/drm/../../../dev/drm/linux_fb.c:82 > > #2 0x808de76b in vt_window_switch (vw=0x81760ea8) > at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:540 > #3 0x808dc280 in vtterm_cngrab (tm=) > at /usr/home/jon/freebsd/graphics/sys/dev/vt/vt_core.c:1465 > #4 0x809f3e02 in cngrab () at > /usr/home/jon/freebsd/graphics/sys/kern/kern_cons.c:368 > #5 0x80a4d27a in vpanic (fmt=0x80ff218f "Assertion %s > failed at %s:%d", > ap=0xfe0233e6f5f0) at > /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:765 > #6 0x80a4d166 in kassert_panic (fmt=) > at /usr/home/jon/freebsd/graphics/sys/kern/kern_shutdown.c:669 > #7 0x80d2b93c in vm_fault_hold (map=0xf8010c9aa000, > vaddr=34369822720, > fault_type=, fault_flags=0, m_hold=0x0) > at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:389 > #8 0x80d2a1b8 in vm_fault (map=0xf8010c9aa000, vaddr= optimized out>, > fault_type=2 '\002', fault_flags=) > at /usr/home/jon/freebsd/graphics/sys/vm/vm_fault.c:474 > #9 0x80ebb412 in trap_pfault (frame=0xfe0233e6f9c0, > usermode=1) > at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:708 > #10 0x80ebaba2 in trap (frame=0xfe0233e6f9c0) > at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/trap.c:326 > #11 0x80e9b181 in calltrap () > at /usr/home/jon/freebsd/graphics/sys/amd64/amd64/exception.S:236 > #12 0x0008022a3876 in ?? () > > It looks like the other core files have the same backtrace. Please let > me know if any other details would help... > > > Jon > -- > jonathan.ander...@ieee.org > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 6 Jan 2017, at 13:53, Pete Wright wrote: i've been having the same problems with iwm too (failing to load firmware on boot). my trick has been to either boot into an old kernel where iwm was mostly usable. also i've commented out the line enabling wlan0 in my rc.conf then uncommented it after boot and manually running "service netif start" to bring up iwm. that method works most of the time... -pete I am able to load iwm (iwm7265fw), but there are some networks that I just can't connect to (INIT -> INIT, swscan_cancel_scan, repeat). Attaching to an iPhone hotspot is one example of a not-entirely-helpful network, but there is other, more typical infrastructure that gives trouble too. There is an iwm8xxx in the room that seems to work fine, however... I do not meddle in the affairs of wi-fi, for it is subtle and quick to anger. :) Jon -- Jonathan Anderson jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
kernel cores tend to be large (all of wired memory after all) and unless I have exactly the same kernel as you with the same sources at the same changeset, not useful. A backtrace is a good place to start. > kgdb /boot/kernel/kernel /var/crash/vmcore.last % bt -M On Fri, 06 Jan 2017 10:53:03 -0800 Pete Wright wrote > > > On 1/6/17 10:44 AM, Jonathan Anderson wrote: > > On 6 Jan 2017, at 12:48, Pete Wright wrote: > > > >> On 1/6/17 9:14 AM, Matthew Macy wrote: > >>> > >>> I just did the merge and it's using a relatively untested new KPI so > >>> regressions aren't too surprising I'm afraid. #96 is more or less > >>> content free in terms of providing useful information. Getting a core > >>> + backtrace would be a lot more helpful. See the repo's wiki for > >>> details on improving your odds of getting a core. > >>> > >> > >> I have found the following has enabled me to catch kernel panic's > >> pretty reliably on the drm-next branch when i have the i915kms module > >> loaded: > >> > >> dev.drm.skip_ddb=1 > > > > Excellent: I turned that on and got a core, then got another core while > > tar'ing up the first core. :) > > > > The machine in question is currently not connected to any network (iwm > > is being a bit unhappy), but once it is, where can I put the tarball? > > > > > oh great! > > i've been having the same problems with iwm too (failing to load > firmware on boot). my trick has been to either boot into an old kernel > where iwm was mostly usable. also i've commented out the line enabling > wlan0 in my rc.conf then uncommented it after boot and manually running > "service netif start" to bring up iwm. that method works most of the > time... > -pete > > -- > Pete Wright > p...@nomadlogic.org > nomadlogicLA > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 1/6/17 10:44 AM, Jonathan Anderson wrote: On 6 Jan 2017, at 12:48, Pete Wright wrote: On 1/6/17 9:14 AM, Matthew Macy wrote: I just did the merge and it's using a relatively untested new KPI so regressions aren't too surprising I'm afraid. #96 is more or less content free in terms of providing useful information. Getting a core + backtrace would be a lot more helpful. See the repo's wiki for details on improving your odds of getting a core. I have found the following has enabled me to catch kernel panic's pretty reliably on the drm-next branch when i have the i915kms module loaded: dev.drm.skip_ddb=1 Excellent: I turned that on and got a core, then got another core while tar'ing up the first core. :) The machine in question is currently not connected to any network (iwm is being a bit unhappy), but once it is, where can I put the tarball? oh great! i've been having the same problems with iwm too (failing to load firmware on boot). my trick has been to either boot into an old kernel where iwm was mostly usable. also i've commented out the line enabling wlan0 in my rc.conf then uncommented it after boot and manually running "service netif start" to bring up iwm. that method works most of the time... -pete -- Pete Wright p...@nomadlogic.org nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 1/6/17 9:14 AM, Matthew Macy wrote: > > Please try the drm-next branch now. Up until very recently, the > > shrinkers responsible for culling ttm/gem allocations were never run. > > I've now implemented the shrinker, but it's driven from vm_lowmem, so > > you'll probably still see what looks like a leak until you hit low > > memory conditions. The shrinker should probably be run from > > uma_timeout, but there isn't an eventhandler for that and I haven't > > looked any further. > > > > -M > > Hi, > > I am now testing the `drm-next` branch, but I'm finding it crashes much > more frequently (a la > https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than > `drm-next-4.7`. While the 4.7 branch would sometimes only last a few > minutes, it would sometimes run for a day or more. On `drm-next`, > however, I think I'm yet to have 20 minutes of uptime. So, I haven't run > into the memory shrinker yet because I haven't had enough uptime to use > lots of memory. :) I will continue testing... any specific things I > ought to be doing? > I just did the merge and it's using a relatively untested new KPI so regressions aren't too surprising I'm afraid. #96 is more or less content free in terms of providing useful information. Getting a core + backtrace would be a lot more helpful. See the repo's wiki for details on improving your odds of getting a core. I have found the following has enabled me to catch kernel panic's pretty reliably on the drm-next branch when i have the i915kms module loaded: dev.drm.skip_ddb=1 -pete -- Pete Wright p...@nomadlogic.org nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
> > Please try the drm-next branch now. Up until very recently, the > > shrinkers responsible for culling ttm/gem allocations were never run. > > I've now implemented the shrinker, but it's driven from vm_lowmem, so > > you'll probably still see what looks like a leak until you hit low > > memory conditions. The shrinker should probably be run from > > uma_timeout, but there isn't an eventhandler for that and I haven't > > looked any further. > > > > -M > > Hi, > > I am now testing the `drm-next` branch, but I'm finding it crashes much > more frequently (a la > https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than > `drm-next-4.7`. While the 4.7 branch would sometimes only last a few > minutes, it would sometimes run for a day or more. On `drm-next`, > however, I think I'm yet to have 20 minutes of uptime. So, I haven't run > into the memory shrinker yet because I haven't had enough uptime to use > lots of memory. :) I will continue testing... any specific things I > ought to be doing? > I just did the merge and it's using a relatively untested new KPI so regressions aren't too surprising I'm afraid. #96 is more or less content free in terms of providing useful information. Getting a core + backtrace would be a lot more helpful. See the repo's wiki for details on improving your odds of getting a core. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 5 Jan 2017, at 0:17, Matthew Macy wrote: On Mon, 02 Jan 2017 06:01:50 -0800 Jonathan Anderson wrote Hi all, I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of not-quite-CURRENT, it's also very possible that I don't understand how the laundry queue is supposed to work. Nonetheless, I thought I'd check whether there is a tunable I should change, an issue with the laundry queue itself, etc. After running X overnight (i915 can now run overnight on drm-next-4.7!), I end up with a little over half of my system memory in the laundry queue and a bunch of swap utilization. Even after closing X and shutting down lots of services, I see the following in top: Please try the drm-next branch now. Up until very recently, the shrinkers responsible for culling ttm/gem allocations were never run. I've now implemented the shrinker, but it's driven from vm_lowmem, so you'll probably still see what looks like a leak until you hit low memory conditions. The shrinker should probably be run from uma_timeout, but there isn't an eventhandler for that and I haven't looked any further. -M Hi, I am now testing the `drm-next` branch, but I'm finding it crashes much more frequently (a la https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues/96) than `drm-next-4.7`. While the 4.7 branch would sometimes only last a few minutes, it would sometimes run for a day or more. On `drm-next`, however, I think I'm yet to have 20 minutes of uptime. So, I haven't run into the memory shrinker yet because I haven't had enough uptime to use lots of memory. :) I will continue testing... any specific things I ought to be doing? Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On 2 Jan 2017, at 13:33, Mark Johnston wrote: On Mon, Jan 02, 2017 at 10:31:50AM -0330, Jonathan Anderson wrote: Hi all, I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of not-quite-CURRENT, it's also very possible that I don't understand how the laundry queue is supposed to work. Nonetheless, I thought I'd check whether there is a tunable I should change, an issue with the laundry queue itself, etc. My suspicion is that this is a memory leak of some sort and unrelated to PQ_LAUNDRY itself. That is, with the previous policy you would see lots of swap usage and a large inactive queue instead. That sounds very plausible... I'm testing with the new DRM drivers to see if that helps. After running X overnight (i915 can now run overnight on drm-next-4.7!), I end up with a little over half of my system memory in the laundry queue and a bunch of swap utilization. Even after closing X and shutting down lots of services, I see the following in top: ``` Mem: 977M Active, 31M Inact, 4722M Laundry, 1917M Wired, 165M Free ARC: 697M Total, 67M MFU, 278M MRU, 27K Anon, 22M Header, 331M Other Swap: 4096M Total, 2037M Used, 2059M Free, 49% Inuse PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 911 root 1 520 57788K 4308K select 1 0:00 0.00% sshd 974 root 1 200 43780K 0K wait2 0:00 0.00% 1406 jon 1 200 33520K 2748K select 0 0:04 0.00% gpg-agent 2038 jon 1 200 31280K 5452K ttyin 3 0:18 0.00% zsh 1251 jon 1 220 31280K 4500K pause 3 0:02 1.46% zsh 7102 jon 1 200 31280K 3744K ttyin 0 0:00 0.00% zsh 1898 jon 1 200 31280K 3036K ttyin 1 0:00 0.00% zsh 1627 jon 1 210 31280K 0K pause 0 0:00 0.00% 22989 jon 1 200 31152K 6020K ttyin 1 0:01 0.00% zsh 22495 jon 1 490 31152K 6016K ttyin 0 0:02 0.00% zsh 1621 jon 1 200 28196K 8816K select 2 0:40 0.00% tmux 6214 jon 1 520 27008K 2872K ttyin 1 0:00 0.00% zsh 6969 jon 1 520 27008K 2872K ttyin 3 0:00 0.00% zsh 6609 root 1 200 20688K 4604K select 1 0:00 0.00% wpa_supplicant 914 root 1 200 20664K 5232K select 2 0:02 0.00% sendmail 917 smmsp 1 200 20664K 0K pause 0 0:00 0.00% 24206 jon 1 230 20168K 3500K CPU00 0:00 0.00% top 921 root 1 200 12616K 608K nanslp 1 0:00 0.00% cron ``` Are there any things I could do (e.g., sysctls, tunables) to figure out what's happening? Can I manually force the laundry to be done? `swapoff -a` fails due to a lack of memory. Is that the full list of processes? Does "ipcs -m" show any named shm segments? Looking at the DRM code, the GEM uses swap objects to back allocations by the drivers, so this could be the result of a kernel page leak in the drm-next branch. If so, you'll need a reboot to recover. That was the full list of processes, yes. I haven't been able to reproduce this particular issue on new DRM code, as I'm now confronted with a different issue. :) If I do get back to this condition, I'll try checking `ipcs -m`, thanks. Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On Mon, 02 Jan 2017 06:01:50 -0800 Jonathan Anderson wrote > Hi all, > > I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close > to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of > not-quite-CURRENT, it's also very possible that I don't understand how the > laundry queue is supposed to work. Nonetheless, I thought I'd check whether > there is a tunable I should change, an issue with the laundry queue itself, > etc. > > After running X overnight (i915 can now run overnight on drm-next-4.7!), I > end up with a little over half of my system memory in the laundry queue and > a bunch of swap utilization. Even after closing X and shutting down lots of > services, I see the following in top: Please try the drm-next branch now. Up until very recently, the shrinkers responsible for culling ttm/gem allocations were never run. I've now implemented the shrinker, but it's driven from vm_lowmem, so you'll probably still see what looks like a leak until you hit low memory conditions. The shrinker should probably be run from uma_timeout, but there isn't an eventhandler for that and I haven't looked any further. -M > Mem: 977M Active, 31M Inact, 4722M Laundry, 1917M Wired, 165M Free > ARC: 697M Total, 67M MFU, 278M MRU, 27K Anon, 22M Header, 331M Other > Swap: 4096M Total, 2037M Used, 2059M Free, 49% Inuse > > PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU > COMMAND > 911 root 1 520 57788K 4308K select 1 0:00 0.00% sshd > 974 root 1 200 43780K 0K wait2 0:00 0.00% > > 1406 jon 1 200 33520K 2748K select 0 0:04 0.00% > gpg-agent > 2038 jon 1 200 31280K 5452K ttyin 3 0:18 0.00% zsh > 1251 jon 1 220 31280K 4500K pause 3 0:02 1.46% zsh > 7102 jon 1 200 31280K 3744K ttyin 0 0:00 0.00% zsh > 1898 jon 1 200 31280K 3036K ttyin 1 0:00 0.00% zsh > 1627 jon 1 210 31280K 0K pause 0 0:00 0.00% > 22989 jon 1 200 31152K 6020K ttyin 1 0:01 0.00% zsh > 22495 jon 1 490 31152K 6016K ttyin 0 0:02 0.00% zsh > 1621 jon 1 200 28196K 8816K select 2 0:40 0.00% tmux > 6214 jon 1 520 27008K 2872K ttyin 1 0:00 0.00% zsh > 6969 jon 1 520 27008K 2872K ttyin 3 0:00 0.00% zsh > 6609 root 1 200 20688K 4604K select 1 0:00 0.00% > wpa_supplicant > 914 root 1 200 20664K 5232K select 2 0:02 0.00% > sendmail > 917 smmsp 1 200 20664K 0K pause 0 0:00 0.00% > > 24206 jon 1 230 20168K 3500K CPU00 0:00 0.00% top > 921 root 1 200 12616K 608K nanslp 1 0:00 0.00% cron > ``` > > Are there any things I could do (e.g., sysctls, tunables) to figure out > what's happening? Can I manually force the laundry to be done? `swapoff -a` > fails due to a lack of memory. > > Thanks, > > > Jon > -- > jonat...@freebsd.org > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: PQ_LAUNDRY: unexpected behaviour
On Mon, Jan 02, 2017 at 10:31:50AM -0330, Jonathan Anderson wrote: > Hi all, > > I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close > to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of > not-quite-CURRENT, it's also very possible that I don't understand how the > laundry queue is supposed to work. Nonetheless, I thought I'd check whether > there is a tunable I should change, an issue with the laundry queue itself, > etc. My suspicion is that this is a memory leak of some sort and unrelated to PQ_LAUNDRY itself. That is, with the previous policy you would see lots of swap usage and a large inactive queue instead. > > After running X overnight (i915 can now run overnight on drm-next-4.7!), I > end up with a little over half of my system memory in the laundry queue and > a bunch of swap utilization. Even after closing X and shutting down lots of > services, I see the following in top: > > ``` > Mem: 977M Active, 31M Inact, 4722M Laundry, 1917M Wired, 165M Free > ARC: 697M Total, 67M MFU, 278M MRU, 27K Anon, 22M Header, 331M Other > Swap: 4096M Total, 2037M Used, 2059M Free, 49% Inuse > > PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU > COMMAND > 911 root 1 520 57788K 4308K select 1 0:00 0.00% sshd > 974 root 1 200 43780K 0K wait2 0:00 0.00% > > 1406 jon 1 200 33520K 2748K select 0 0:04 0.00% > gpg-agent > 2038 jon 1 200 31280K 5452K ttyin 3 0:18 0.00% zsh > 1251 jon 1 220 31280K 4500K pause 3 0:02 1.46% zsh > 7102 jon 1 200 31280K 3744K ttyin 0 0:00 0.00% zsh > 1898 jon 1 200 31280K 3036K ttyin 1 0:00 0.00% zsh > 1627 jon 1 210 31280K 0K pause 0 0:00 0.00% > 22989 jon 1 200 31152K 6020K ttyin 1 0:01 0.00% zsh > 22495 jon 1 490 31152K 6016K ttyin 0 0:02 0.00% zsh > 1621 jon 1 200 28196K 8816K select 2 0:40 0.00% tmux > 6214 jon 1 520 27008K 2872K ttyin 1 0:00 0.00% zsh > 6969 jon 1 520 27008K 2872K ttyin 3 0:00 0.00% zsh > 6609 root 1 200 20688K 4604K select 1 0:00 0.00% > wpa_supplicant > 914 root 1 200 20664K 5232K select 2 0:02 0.00% > sendmail > 917 smmsp 1 200 20664K 0K pause 0 0:00 0.00% > > 24206 jon 1 230 20168K 3500K CPU00 0:00 0.00% top > 921 root 1 200 12616K 608K nanslp 1 0:00 0.00% cron > ``` > > Are there any things I could do (e.g., sysctls, tunables) to figure out > what's happening? Can I manually force the laundry to be done? `swapoff -a` > fails due to a lack of memory. Is that the full list of processes? Does "ipcs -m" show any named shm segments? Looking at the DRM code, the GEM uses swap objects to back allocations by the drivers, so this could be the result of a kernel page leak in the drm-next branch. If so, you'll need a reboot to recover. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
PQ_LAUNDRY: unexpected behaviour
Hi all, I'm seeing some unexpected PQ_LAUNDRY behaviour on something fairly close to -CURRENT (drm-next-4.7 with an IFC on 26 Dec). Aside from the use of not-quite-CURRENT, it's also very possible that I don't understand how the laundry queue is supposed to work. Nonetheless, I thought I'd check whether there is a tunable I should change, an issue with the laundry queue itself, etc. After running X overnight (i915 can now run overnight on drm-next-4.7!), I end up with a little over half of my system memory in the laundry queue and a bunch of swap utilization. Even after closing X and shutting down lots of services, I see the following in top: ``` Mem: 977M Active, 31M Inact, 4722M Laundry, 1917M Wired, 165M Free ARC: 697M Total, 67M MFU, 278M MRU, 27K Anon, 22M Header, 331M Other Swap: 4096M Total, 2037M Used, 2059M Free, 49% Inuse PID USERNAMETHR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 911 root 1 520 57788K 4308K select 1 0:00 0.00% sshd 974 root 1 200 43780K 0K wait2 0:00 0.00% 1406 jon 1 200 33520K 2748K select 0 0:04 0.00% gpg-agent 2038 jon 1 200 31280K 5452K ttyin 3 0:18 0.00% zsh 1251 jon 1 220 31280K 4500K pause 3 0:02 1.46% zsh 7102 jon 1 200 31280K 3744K ttyin 0 0:00 0.00% zsh 1898 jon 1 200 31280K 3036K ttyin 1 0:00 0.00% zsh 1627 jon 1 210 31280K 0K pause 0 0:00 0.00% 22989 jon 1 200 31152K 6020K ttyin 1 0:01 0.00% zsh 22495 jon 1 490 31152K 6016K ttyin 0 0:02 0.00% zsh 1621 jon 1 200 28196K 8816K select 2 0:40 0.00% tmux 6214 jon 1 520 27008K 2872K ttyin 1 0:00 0.00% zsh 6969 jon 1 520 27008K 2872K ttyin 3 0:00 0.00% zsh 6609 root 1 200 20688K 4604K select 1 0:00 0.00% wpa_supplicant 914 root 1 200 20664K 5232K select 2 0:02 0.00% sendmail 917 smmsp 1 200 20664K 0K pause 0 0:00 0.00% 24206 jon 1 230 20168K 3500K CPU00 0:00 0.00% top 921 root 1 200 12616K 608K nanslp 1 0:00 0.00% cron ``` Are there any things I could do (e.g., sysctls, tunables) to figure out what's happening? Can I manually force the laundry to be done? `swapoff -a` fails due to a lack of memory. Thanks, Jon -- jonat...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"