From: Christoph Hellwig <hch@lst.de>
To: Shaohua Li <shli@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>,
linux-block@vger.kernel.org, axboe@fb.com,
Shaohua Li <shli@fb.com>
Subject: Re: [PATCH 2/2] block: delete bio_uninit
Date: Thu, 13 Jul 2017 19:23:47 +0200 [thread overview]
Message-ID: <20170713172347.GC5107@lst.de> (raw)
In-Reply-To: <20170713165023.vcnumrgvbu4cw6jx@kernel.org>
On Thu, Jul 13, 2017 at 09:50:23AM -0700, Shaohua Li wrote:
> > As said in the last mail I think there is no point in having this call..
>
> I'm hesitant to do this. bio_associate_blkcg/bio_associate_current can be
> called in any time for a bio, so we not just attach cgroup info to info in bio
> submit (maybe the bio_associate_blkcg/bio_associate_current callers do sumbit
> always, but I didn't audit yet).
bio_associate_current is only called from blk_throtl_assoc_bio, which
is only called from blk_throtl_bio, which is only called from
blkcg_bio_issue_check, which is only called from
generic_make_request_checks, which is only called from
generic_make_request, which at that point consumes the bio from the
callers perspective.
bio_associate_blkcg might be a different story, but then we should
treat both very differently.
> The other reason is I'd like
> blk_throtl_bio_endio is only called once for the whole bio not for splitted
> bio, so this depends on bio_free to free cgroup info for chained bio which
> always does bio_put.
Then we'll need to fix that. We really should not require every
caller of bio_init to pair it with a new uninit call, which would be
a whole lot more work.
prev parent reply other threads:[~2017-07-13 17:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 18:00 [PATCH 0/2] block: two cleanup patches Shaohua Li
2017-07-12 18:00 ` [PATCH 1/2] block: delete bio_uninit in blockdev Shaohua Li
2017-07-12 18:00 ` [PATCH 2/2] block: delete bio_uninit Shaohua Li
2017-07-13 7:45 ` Christoph Hellwig
2017-07-13 16:50 ` Shaohua Li
2017-07-13 17:23 ` Christoph Hellwig [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170713172347.GC5107@lst.de \
--to=hch@lst.de \
--cc=axboe@fb.com \
--cc=linux-block@vger.kernel.org \
--cc=shli@fb.com \
--cc=shli@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.