On Sat, Mar 13, 2021 at 6:37 PM Kevin Oberman <rkoberman at gmail.com>
wrote:
> I have been dealing with this for a long time since head back in September
> through 13-stable of Mar-4. I have seen no improvement over this time. It
> seems (my perception without supporting data) that it got worse in the
> timeframe of BETA-3 tag. I was running stable, so not quite BETA-3. It also
> does not help that I have also been bitten by the P-State related freeze
> issue which has some similarities. disabling p-states has almost eliminated
> this issue, though, with only three occurrences since I disabled them in
> late January.
>
> As a result, I don't think it is a recent change, but a problem that
has
> existed for at least 3 months. This was made worse by two hardware issues
> that kept the system unavailable for most of the time between buying it
> last spring and getting the keyboard replaced in January. (Both the
> mainboard and the disk drive had already been replaced.) There was another
> slow I/O issue that I had assumed was the same as mine, but was reportedly
> fixed with BETA-4. A few are still seeing slow I/O, so I assume that there
> were different issues with I/O. Since CometLake systems seem pretty
> uncommon, it might be related to that.
>
It was a change from last fall, or set of changes. RC1 or defintely RC2 has
fixes to regain performance lost. If BETA4 was the last one you evaluated,
perhaps you could do a couple tests with RC2 now that it's out to see if it
is the same thing?
Warner
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkoberman at gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
> On Sat, Mar 13, 2021 at 4:36 PM Warner Losh <imp at bsdimp.com>
wrote:
>
>>
>>
>> On Sat, Mar 13, 2021 at 5:33 PM Kevin Oberman <rkoberman at
gmail.com>
>> wrote:
>>
>>> Just spent a little time looking at my issue and have a few more
notes:
>>>
>>
>> What version did you evaluate? There's a number of changes lately
that
>> could have a big impact on this...
>>
>> Warner
>>
>>
>>> Seems to only occur on large r/w operations from/to the same disk.
"sp
>>> big-file /other/file/on/same/disk" or tar/untar operations on
large
>>> files.
>>> Hit this today updating firefox.
>>>
>>> I/O starts at >40MB/s. Dropped to about 1.5MB/s. If I tried
doing other
>>> things while it was running slowly, the disk would appear to lock
up.
>>> E.g.
>>> pwd(1) seemed to completely lock up the system, but I could still
ping it
>>> and, after about 30 seconds, things came back to life. It was also
not
>>> instantaneous. Disc activity dropped to <1MB/s for a few seconds
before
>>> everything froze.
>>>
>>> During the untar of firefox, I saw; this several times. I also
looked at
>>> my
>>> console where I found these errors during :
>>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 55043, size:
8192
>>> swap_pager: indefinite wait buffer: bufobj: 0, blkno: 51572, size:
4096
>>>
>>> I should note that some operations continue just fine while this is
going
>>> on until I do something that freezes the system. I assume that this
>>> eliminates the disk drive and low-level driver. Is vfs a possible
issue.
>>> It
>>> had some serious work in the past few months by markj. That does
not
>>> explain why more people are not seeing this.
>>>
>>> I have been seeing this since at least September 2020, so it goes
back a
>>> way. As this CometLake system will not run graphics on 12, I
can't
>>> confirm
>>> operation before 13.
>>> --
>>> Kevin Oberman, Part time kid herder and retired Network Engineer
>>> E-mail: rkoberman at gmail.com
>>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>>
>>>
>>> On Fri, Mar 5, 2021 at 10:47 PM Mark Millard via freebsd-stable
<
>>> freebsd-stable at freebsd.org> wrote:
>>>
>>> >
>>> > Konstantin Belousov kostikbel at gmail.com wrote on
>>> > Fri Mar 5 23:12:13 UTC 2021 :
>>> >
>>> > > On Sat, Mar 06, 2021 at 12:27:55AM +0200, Christos
Chatzaras wrote:
>>> > . . .
>>> > > > Command: /usr/bin/time -l portsnap extract (these
tests done with 2
>>> > different idle servers but with same 4TB HDDs models)
>>> > > >
>>> > > > FreeBSD 12.2p4
>>> > > >
>>> > > > 99.45 real 34.90 user 59.63 sys
>>> > > > 100.00 real 34.91 user 59.97 sys
>>> > > > 82.95 real 35.98 user 60.68 sys
>>> > > >
>>> > > > FreeBSD 13.0-RC1
>>> > > >
>>> > > > 217.43 real 75.67 user 110.97 sys
>>> > > > 125.50 real 63.00 user 96.47 sys
>>> > > > 118.93 real 62.91 user 96.28 sys
>>> > > . . .
>>> > > In the portsnap results for 13RC1, the variance is too
high to
>>> conclude
>>> > > anything, I think.
>>> >
>>> > I'll note that there are other reports of wide variance
>>> > in transfer rates observed during an overall operation
>>> > such as "make extract". The one I'm thinking of
is:
>>> >
>>> >
>>>
https://lists.freebsd.org/pipermail/freebsd-stable/2021-March/093251.html
>>> >
>>> > which is an update to earlier reports, but based on more
recent
>>> > stable/13.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253968
>>> > comment 4 has some more notes about the context. The
"make extract"
>>> > for firefox likely is not as complicated as the portsnap
extract
>>> > example's execution structure.
>>> >
>>> > Might be something to keep an eye on if there are on-going
>>> > examples of over time.
>>> >
>>> > ==>>> > Mark Millard
>>> > marklmi at yahoo.com
>>> > ( dsl-only.net went
>>> > away in early 2018-Mar)
>>> >
>>> > _______________________________________________
>>> > freebsd-stable at freebsd.org mailing list
>>> > https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> > To unsubscribe, send any mail to "
>>> freebsd-stable-unsubscribe at freebsd.org"
>>> >
>>> _______________________________________________
>>> freebsd-stable at freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
>>> To unsubscribe, send any mail to "freebsd-stable-unsubscribe
at freebsd.org
>>> "
>>>
>>