Re: [PATCH v2] delayacct: Account blkio completion on the correct task
On Mon, Dec 18, 2017 at 9:45 PM, Josh Snyder <jo...@netflix.com> wrote:
> Before commit e33a9bba85a8 ("sched/core: move IO scheduling accounting from
> io_schedule_timeout() into scheduler"), delayacct_blkio_end was called after
> context-switching into the task which completed I/O. This resulted in double
> counting: the task would account a delay both waiting for I/O and for time
> spent in the runqueue.
>
Yes, we included the time spent in the runqueue to delays on account of I/O.
> With e33a9bba85a8, delayacct_blkio_end is called by try_to_wake_up. In
> ttwu, we have not yet context-switched. This is more correct, in that the
> delay accounting ends when the I/O is complete. But delayacct_blkio_end
> relies upon `get_current()`, and we have not yet context-switched into the
> task whose I/O completed. This results in the wrong task having its delay
> accounting statistics updated.
>
> Instead of doing that, pass the task_struct being woken to
> delayacct_blkio_end, so that it can update the statistics of the correct
> task.
>
> Fixes: e33a9bba85a8 ("sched/core: move IO scheduling accounting from
> io_schedule_timeout() into scheduler")
> Signed-off-by: Josh Snyder <jo...@netflix.com>
> ---
Acked-by: Balbir Singh <bsinghar...@gmail.com>
Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications
On Wed, Dec 14, 2016 at 5:15 AM, Jerome Glisse <jgli...@redhat.com> wrote: > I would like to discuss un-addressable device memory in the context of > filesystem and block device. Specificaly how to handle write-back, read, > ... when a filesystem page is migrated to device memory that CPU can not > access. > > I intend to post a patchset leveraging the same idea as the existing > block bounce helper (block/bounce.c) to handle this. I believe this is > worth discussing during summit see how people feels about such plan and > if they have better ideas. > > Yes, that would be interesting. I presume all of this is for ZONE_DEVICE and HMM. I think designing such an interface requires careful thought on tracking pages to ensure we don't lose writes and also the impact on things like the writeback subsytem. >From a HMM perspective and an overall MM perspective, I worry that our accounting system is broken with the proposed mirroring and unaddressable memory that needs to be addressed as well. It would also be nice to have a discussion on migration patches currently on the list 1. THP migration 2. HMM migration 3. Async migration > I also like to join discussions on: > - Peer-to-Peer DMAs between PCIe devices > - CDM coherent device memory Yes, this needs discussion. Specifically from is all of CDM memory NORMAL or not and the special requirements we have today for CDM. > - PMEM > - overall mm discussions Balbir Singh. -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
