Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 04 Mar 2018 11:46:11 -0700
From:      Ian Lepore <ian@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>, bob prohaska <fbsd@www.zefox.net>
Cc:        "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>
Subject:   Re: Is maximum swap usage tunable?
Message-ID:  <1520189171.38056.2.camel@freebsd.org>
In-Reply-To: <CANCZdfpcccDuhJh4EF0C4KFz=dcN5mWvQ9aMiyF53kD=hMzy3Q@mail.gmail.com>
References:  <20180228170311.GA26187@www.zefox.net> <a759ecea-83f4-b0b2-7113-c39633f68637@mgm51.com> <20180228185517.GB26187@www.zefox.net> <8f422161-885e-aa91-eacd-018540222d65@mgm51.com> <20180228214301.GA29481@www.zefox.net> <b82801b8-bc29-414c-1170-621bb4a5d937@mgm51.com> <CANCZdfq_MpxjUyVd-=%2BMiAQAER4TeDh9irhx_evdXwa3yt3h0g@mail.gmail.com> <20180303162605.GA41874@www.zefox.net> <20180304182831.GA44154@www.zefox.net> <CANCZdfpcccDuhJh4EF0C4KFz=dcN5mWvQ9aMiyF53kD=hMzy3Q@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2018-03-04 at 11:35 -0700, Warner Losh wrote:
> On Sun, Mar 4, 2018 at 11:28 AM, bob prohaska <fbsd@www.zefox.net> wrote:
> 
> > 
> > On Sat, Mar 03, 2018 at 08:26:05AM -0800, bob prohaska wrote:
> > > 
> > > 
> > > Is there some sort of experiment which can distinguish hardware delays
> > > from software delays? For example, would logging gstat output shed any
> > > light?
> > > 
> > For lack of any better ideas, I tried running
> > make -j2 -DNO_CLEAN buildworld > buildworld.log && make -j2 -DNO_CLEAN
> > KERNCONF=
> > ZEFOX buildkernel > buildkernel.log
> > 
> > while also running
> > gstat -a -B -I 10s > j2_gstat.log & in another ssh session
> > 
> > In due course the console reported
> > 
> > FreeBSD/arm64 (www.zefox.org) (ttyu0)
> > 
> > login: Mar  4 09:28:30 www kernel: pid 9310 (c++), uid 0, was killed: out
> > of swap space
> > 
> > as expected.
> > 
> > However, a grep of j2_gstat  revealed a maximum write delay of 30ms/w
> > for swap on microSD.
> > 
> > Swap on USB flash is slower, but still generally under 100 ms.
> > Only a handful of widely spaced delays exceeded 200 ms/w.
> > 
> gstat doesn't tell you the worst-case. It tells you the average of the
> requests. This can (and does) hide very long outlier behavior which drives
> the crazy delayed swap messages.
> 
> The worst-case events were
> > 
> > dT: 10.002s  w: 10.000s
> >  L(q)  ops/s    r/s   kBps   ms/r    w/s   kBps   ms/w   %busy Name
> > 
> >     0      6      0      0    0.0      6    113   14.6    3.3  da0b
> >     0      4      0      0    0.0      4     48   29.0    3.1  da0b
> >     0      9      5     79    3.0      5     47    7.9    2.6  da0b
> >     4      8      0      0    0.0      8     99   67.5   32.5  da0b
> >     0      1      0     13    5.6      1     28   5674   88.3  da0b
> >     0      0      0      0    0.0      0     38   18.6    0.3  da0b
> >     0      1      1      9    2.8      0      0    0.0    0.2  da0b
> >     0      1      1     26    5.1      0      0    0.0    0.4  da0b
> >     0      0      0      3    2.6      0      0    0.0    0.1  da0b
> >     0      1      1      9  161.8      0      0    0.0   14.3  da0b
> > 
> > No "indefinite delay" warnings were presented on the console.
> > uname -a reports r329893, sources are at 330383.
> > 
> > I hope this is useful information,
> > 
> Despite my quibble over what you're measuring (I look at this stuff all the
> time for Netflix), I think this is quite useful.... Thanks!
> 

I think it would be more useful with a -I1 instead of 10.  Including
the -d flag might also be useful, since deleting is what's so slow on
flash-based devices (I'm not sure if swapping triggers BIO_DELETE
stuff, but other filesystem activity does).

Also, I see a 5-second write latency there at one point. 

-- Ian



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