Re: PQ_LAUNDRY: unexpected behaviour

[Adrian Chadd]

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

[Jonathan Anderson]

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

[Jonathan Anderson]

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

[Jonathan Anderson]

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

[Matthew Macy]

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

[Jonathan Anderson]

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

[Matthew Macy]

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

[Pete Wright]

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

[Pete Wright]

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

[Matthew Macy]

 > > 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

[Jonathan Anderson]

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

[Jonathan Anderson]

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

[Matthew Macy]

  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

[Mark Johnston]

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

[Jonathan Anderson]

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"