Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 02 Sep 2018 19:56:54 +0200
From:      "Ronald Klop" <ronald-lists@klop.ws>
To:        "Mark Millard" <marklmi@yahoo.com>, "bob prohaska" <fbsd@www.zefox.net>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024")
Message-ID:  <op.zop6s4iekndu52@sjakie>
In-Reply-To: <20180902152717.GB44384@www.zefox.net>
References:  <FA3B8541-73E0-4796-B2AB-D55CE40B9654@yahoo.com> <20180814014226.GA50013@www.zefox.net> <CANCZdfqFKY3Woa%2B9pVS5hika_JUAUCxAvLznSS4gaLq2kKoWtQ@mail.gmail.com> <20180815013612.GB51051@www.zefox.net> <CANCZdfoB_AcidFpKT_ZmZWUFnmC4Bw55krK%2BMqEmmj=f9KMQ2Q@mail.gmail.com> <20180815225504.GB59074@www.zefox.net> <20180901230233.GA42895@www.zefox.net> <F3AF3A89-322E-4048-A758-4276C1A1BEA0@yahoo.com> <20180902083217.GA44384@www.zefox.net> <6B8E28DC-075D-4829-9BEA-F36DDB1E2A25@yahoo.com> <20180902152717.GB44384@www.zefox.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 02 Sep 2018 17:27:17 +0200, bob prohaska <fbsd@www.zefox.net>  
wrote:

> On Sun, Sep 02, 2018 at 06:57:15AM -0700, Mark Millard wrote:
>> Was this with or without (presuming a ufs file system):
>>
>> tunefs: trim: (-t)                                         enabled
>>
>> ? If enabled, with or without:
>>
>> sysctl vfs.ffs.dotrimcons=1
>>
>> In other words: was "consolidation of TRIM / BIO_DELETE
>> commands to the UFS/FFS filesystem" enabled? Disabled?
>>
>
> No, it was not. By all accounts TRIM enabling won't affect USB2.0  
> devices,
> and it's fairly clear the bottleneck is in USB, not microSD. Trim is  
> enabled
> for mmcsd0s2a, but sysctl vfs.ffs.dotrimcons=1 hasn't been invoked. I'll  
> turn

Sysctl vfs.ffs.dotrimcons is about FFS/UFS. Not about swap.
So unless there is UFS on the same device as swap, the sysctl will not  
have any effect.

Regards,
Ronald.


> it on later, to check for bad side effects, but there's no obvious  
> reason to
> think it'll help.
>
> At the moment the diskscript is reporting:
>
> dT: 10.005s  w: 10.000s
>  L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w    d/s   kBps    
> ms/d   %busy Name
>     0      0      0      0    0.0      0      9    5.2      0      0     
> 0.0    0.2  mmcsd0
>    10      0      0      0    0.0      0      2  13790      0      0     
> 0.0   89.9  da0
>     0      0      0      0    0.0      0      2    3.9      0      0     
> 0.0    0.1  mmcsd0s2b
>     0      0      0      0    0.0      0      9    5.2      0      0     
> 0.0    0.2  mmcsd0s2
>     9      0      0      0    0.0      0      2  13790      0      0     
> 0.0   89.9  da0b
> Sun Sep  2 08:17:14 PDT 2018
> Device          1K-blocks     Used    Avail Capacity
> /dev/da0b         1048576   494352   554224    47%
> /dev/mmcsd0s2b    1048576   478860   569716    46%
> Total             2097152   973212  1123940    46%
> Sep  2 08:14:38 www kernel: swap_pager: indefinite wait buffer: bufobj:  
> 0, blkno: 1649558, size: 4096
> Sep  2 08:14:38 www kernel: swap_pager: indefinite wait buffer: bufobj:  
> 0, blkno: 1654590, size: 16384
>
> Top is reporting ~10-50% idle time, not surprising given delays writing  
> to da0b.
> I was hoping the pager might favor microSD given the much faster I/O  
> times,
> but evidently not. Seems to be a strict round-robin division of labor.
>
> Thanks for reading!
>
> bob prohaska
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.zop6s4iekndu52>