Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1676939
| From | Jens Axboe <axboe@kernel.dk> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH V4 00/12] blktrace: output cgroup info |
| Date | 2017-06-28 20:00 +0200 |
| Message-ID | <tXppZ-t5-101@gated-at.bofh.it> (permalink) |
| References | <tXppV-t5-19@gated-at.bofh.it> <tXppZ-t5-103@gated-at.bofh.it> <tXppZ-t5-105@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 06/28/2017 10:53 AM, Shaohua Li wrote: > On Wed, Jun 28, 2017 at 10:43:48AM -0600, Jens Axboe wrote: >> On 06/28/2017 10:29 AM, Shaohua Li wrote: >>> From: Shaohua Li <shli@fb.com> >>> >>> Hi, >>> >>> Currently blktrace isn't cgroup aware. blktrace prints out task name of current >>> context, but the task of current context isn't always in the cgroup where the >>> BIO comes from. We can't use task name to find out IO cgroup. For example, >>> Writeback BIOs always comes from flusher thread but the BIOs are for different >>> blk cgroups. Request could be requeued and dispatched from completely different >>> tasks. MD/DM are another examples. This brings challenges if we want to use >>> blktrace for performance tunning with cgroup enabled. >>> >>> This patchset try to fix the gap. We print out cgroup fhandle info in blktrace. >>> Userspace can use open_by_handle_at() syscall to find the cgroup by fhandle. Or >>> userspace can use name_to_handle_at() syscall to find fhandle for a cgroup and >>> use a BPF program to filter out blktrace for a specific cgroup. >>> >>> The first 6 patches adds export operation handlers for kernfs, so userspace can >>> use open_by_handle_at/name_to_handle_at to a kernfs file. Later patches make >>> blktrace output cgroup info. >> >> Series looks fine to me. I don't know how you want to split or funnel it, >> since it touches multiple different parts. Would it make sense to split this >> series into two - one for the kernfs changes, and then a subsequent block >> series that depend on that? > > What's the best practice to do this without building errors? Ask Tejun > to merge the first 7 patches first? Yes, and then resend the block patches, just noting that dependency. Then we can funnel them in like that. -- Jens Axboe
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [PATCH V4 00/12] blktrace: output cgroup info Jens Axboe <axboe@kernel.dk> - 2017-06-28 20:00 +0200
Re: [PATCH V4 00/12] blktrace: output cgroup info Tejun Heo <tj@kernel.org> - 2017-06-28 20:20 +0200
Re: [PATCH V4 00/12] blktrace: output cgroup info Jens Axboe <axboe@kernel.dk> - 2017-06-28 23:00 +0200
Re: [PATCH V4 00/12] blktrace: output cgroup info Tejun Heo <tj@kernel.org> - 2017-06-28 23:30 +0200
Re: [PATCH V4 00/12] blktrace: output cgroup info Greg KH <gregkh@linuxfoundation.org> - 2017-06-29 15:00 +0200
Re: [PATCH V4 00/12] blktrace: output cgroup info Shaohua Li <shli@kernel.org> - 2017-06-29 20:40 +0200
csiph-web