On 2021-Mar-22, at 22:51, Kevin Oberman wrote:
> On Mon, Mar 22, 2021 at 8:19 AM Adrian Chadd wrote:
>> On Mon, 15 Mar 2021 at 14:58, Kevin Oberman wrote:
>>
>> > >
>> > > It appears that the messages are associated with reading
>> > > the disk(s), not directly with writing them, where the
>> > > reads take more than "hz * 20" time units to complete.
>> > > (I'm looking at main (14) code.) What might contribute
>> > > to the time taken for the pending read(s)?
>> > >
>> > The reference to hz * 20 woke up a few sleeping memory cells. I forgot that
>> > I cleaned up my loader.conf. It was largely a copy of the one on my
>> > decade-old T520. I commented out "kern.hz=100". I don't recall the details,
>> > but I think it was actually from an even older system, my T42 from before I
>> > retired.
>> >
>> > In any case, restoring this setting has greatly improved the situation. I
>> > now have really bad disk I/O performance on large disk to disk activity
>> > (untarring the firefox distro) instead of terrible performance and the
>> > system freezes have vanished, though I do see pauses in response to clicks
>> > or text entry, but the display remains active and the pauses are short... 1
>> > to 15 seconds, I'd guess. No, I have no idea what this indicates.
>>
>> ... which drive controller is this? Is it just a laptop ATA disk?
>>
>> > I'm still not seeing the performance I was seeing back in February when 40
>> > MB/s for extended intervals was common and I once untarred firefox.tar.gz2
>> > in under a minute and performance seldom dropped below 1.4 MB/s.
>>
>> Did you find a resolution? I wonder if setting kern.hz is kicking
>> some process(es) to get some time more frequently due to bugs
>> elsewhere in the system (interrupts, IPI handling, wake-ups, etc)
>>
>>
>>
>> -adrian
> No resolution. This is a Lenovo L15 ThinkPad with a 2TB ATAPI drive.
I've not found documentation indicating the "which drive
controller" answer. That may have to be answered from boot
messages or boot -v messages or other such on FreeBSD.
(I've no access to such a machine.)
You might want to put a copy of such a log someplace that
folks could look at it. There may be commands that some
folks would like to see the output of. (I'm not all that
likely to be one that could put such to use but other
folks might be able to.)
Intel® Celeron®? 10th Generation Intel CoreTM i3? i5? i7?
> The current drive is a Seagate. All testing has been done since I got it
> back from Lenovo in late January. I can read or write the drive at reasonable
> rates that exceed 50 MB/s. Extracting a tar distribution file is painful. I
> have had firefox extracts take over a half hour. Worse, if I do other
> operations while the extract is taking place, I often see a 30 second (and,
> occasionally 60 second) display freezes
I thought that you had reported that use of kern.hz=100
had lead to "the system freezes have vanished" and "pauses
are short... 1 to 15 seconds". Did more testing show that
to not be always the case?
> as well as log reports that of "swap_pager: indefinite wait buffer:"
Unfortunately, I do not know how to investigate what is leading to
those message being generated. Figuring that out would seem to be
important but I do not know what to monitor to at least potentially
eliminate some possibilities.
One possible thing to look at is something like "gstat -spod"
output spanning the time of the untar. It would at least
indicate if a large queue backlog was accumulating on the
device. And the ms/r and ms/w columns would give a clue if
commands are sitting in the queues for long periods. (The
"d" may be a waste: no BIO_DELETEs possible? Also, the r/s
vs. ms/r are not rescaled reciprocals but distinct
measurements. Similarly for: the w/s vs. ms/w.)
Given the "indefinite wait buffer" messages, I expect
the ms/r and/or ms/w figures to be large at least some
of the time. Knowing how large may be of use to someone.
But I can not eliminate anything with such information.
> This is a bit odd as I have 20G of RAM and am pretty close to no swap space
> activity, but, of course, paging does occur.
With 20 GiBytes of RAM, what is going on at the time that
leads to paging activity? I'm thinking of just untarring
the firefox file, not building firefox or such. Can you
test such an untar in a context that is not otherwise
paging (nor swapping)? If yes, is the behavior different
in any readily noticeable way?
> This system is CometLake and graphics are not supported on 12. I am not
> absolutely sure that there is not a hardware issue even though the main
> board, the disk, and the keyboard/mouse pad have all been replace since I
> received the system back last June. I now wonder what else could go wrong.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
