RPI3 swap experiments (r338342 with vm.pageout_oom_seq="1024")

Ian Lepore ian at freebsd.org
Sun Sep 2 16:39:03 UTC 2018


On Sun, 2018-09-02 at 08:27 -0700, bob prohaska 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
> it on later, to check for bad side effects, but there's no obvious reason to
> think it'll help.

Trim consolidation at the ufs layer might not have as much effect on
mmcsd as it does on other devices. The mmcsd driver has always
consolidated adjacent trim requests itself even when they arrive in the
IO queue as a large number of small BIO_DELETE commands. It assembles
blocks of adjacent deletes until they reach the size of a full erase
block, then issue one erase command (I've never been convinced that
doing so is necessary, to me the sd spec implies you can delete
individual sectors).

-- Ian


More information about the freebsd-arm mailing list