Messages in this thread | | | Date | Wed, 8 Sep 2021 07:36:40 -0400 | From | Johannes Weiner <> | Subject | Re: [PATCH] mm : bail out from psi memstall after submit_bio in swap_readpage |
| |
On Wed, Sep 08, 2021 at 11:35:40AM +0800, Zhaoyang Huang wrote: > On Tue, Sep 7, 2021 at 9:24 PM Johannes Weiner <hannes@cmpxchg.org> wrote: > > > > On Tue, Sep 07, 2021 at 08:15:30PM +0800, Zhaoyang Huang wrote: > > > On Tue, Sep 7, 2021 at 8:03 PM Vlastimil Babka <vbabka@suse.cz> wrote: > > > > > > > > On 9/7/21 13:59, Huangzhaoyang wrote: > > > > > From: Zhaoyang Huang <zhaoyang.huang@unisoc.com> > > > > > > > > > > It doesn't make sense to count IO time into psi memstall. Bail out after > > > > > bio submitted. > > > > > > > > Isn't that the point if psi, to observe real stalls, which include IO? > > > > Yes, correct. > > > > > IO stalls could be observed within blk_io_schedule. The time cost of > > > the data from block device to RAM is counted here. > > > > Yes, that is on purpose. The time a thread waits for swap read IO is > > time in which the thread is not productive due to a lack of memory. > > > > For async-submitted IO, this happens in lock_page() called from > > do_swap_page(). If the submitting thread directly waits after the > > submit_bio(), then that should be accounted too. > IMO, memstall counting should be terminated by bio submitted. blk > driver fetching request and the operation on the real device shouldn't > be counted in. It especially doesn't make sense in a virtualization > system like XEN etc, where the blk driver is implemented via > backend-frontend way that introduce memory irrelevant latency
Yes but the entire IO operation and all the associated latency only happens due to a shortage of memory in the first place. The thread is incurring these delays due to a lack of memory.
What is a memstall if not the latencies and wait times incurred in the process of reloading pages that were evicted prematurely?
| |