All of lore.kernel.org
 help / color / mirror / Atom feed
From: Damien Le Moal <Damien.LeMoal@wdc.com>
To: Matthew Wilcox <willy@infradead.org>, Christoph Hellwig <hch@lst.de>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
	'Jens Axboe ' <axboe@kernel.dk>,
	"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH] block: Add bio_limit
Date: Mon, 18 Jan 2021 23:52:10 +0000	[thread overview]
Message-ID: <BL0PR04MB6514A4BFE2EA5AE59795E586E7A40@BL0PR04MB6514.namprd04.prod.outlook.com> (raw)
In-Reply-To: 20210118192048.GF2260413@casper.infradead.org

On 2021/01/19 4:26, Matthew Wilcox wrote:
> On Mon, Jan 18, 2021 at 07:31:13PM +0100, Christoph Hellwig wrote:
>> On Mon, Jan 18, 2021 at 06:17:12PM +0000, Matthew Wilcox wrote:
>>> On Mon, Jan 18, 2021 at 07:13:38PM +0100, Christoph Hellwig wrote:
>>>> On Thu, Jan 14, 2021 at 07:47:06PM +0000, Matthew Wilcox (Oracle) wrote:
>>>>> It's often inconvenient to use BIO_MAX_PAGES due to min() requiring the
>>>>> sign to be the same.  Introduce bio_limit() and change BIO_MAX_PAGES to
>>>>> be unsigned to make it easier for the users.
>>>>>
>>>>> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
>>>>
>>>> I like the helper, but I'm not too happy with the naming.  Why not
>>>> something like bio_guess_nr_segs() or similar?
>>>
>>> This feels like it's a comment on an entirely different patch, like this one:
>>>
>>> https://git.infradead.org/users/willy/pagecache.git/commitdiff/fe9841debe24e15100359acadd0b561bbb2dceb1
>>>
>>> bio_limit() doesn't guess anything, it just clamps the argument to
>>> BIO_MAX_PAGES (which is itself misnamed; it's BIO_MAX_SEGS now)
>>
>> No, it was for thi patch.  Yes, it divides and clamps.  Which is sort of
>> a guess as often we might need less of them.  That being said I'm not
>> very fond of my suggestion either, but limit sounds wrong as well.
> 
> bio_limit() doesn't divide.  Some of the callers divide.
> 
> +static inline unsigned int bio_limit(unsigned int nr_segs)
> +{
> +       return min(nr_segs, BIO_MAX_PAGES);
> +}
> 
> I'd rather the callers didn't have to worry about this at all (just pass
> in a number and then deal with however many bvecs you were given), but
> there are callers which depend on the current if-too-big-return-NULL
> behaviour, and I don't want to track all of those down and fix them.
> 
> I chose limit because it's imposing the bio's limit.  Could be called
> bio_clamp(), but the bio also doesn't impose a minimum, so that seemed
> wrong.
> 

What about calling it bio_max_bvecs() or bio_max_segs() ? Together with renaming
BIO_MAX_PAGES to BIO_MAX_SEGS or BIO_MAX_BVECS, things would be clear on what
this is referring to. Since these days one bvec is one seg, but segment is more
struct request layer while bvec is more BIO layer, I would lean toward using
bvec for naming this one, but either way would be fine I think.

-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2021-01-18 23:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-14 19:47 [PATCH] block: Add bio_limit Matthew Wilcox (Oracle)
2021-01-18 18:13 ` Christoph Hellwig
2021-01-18 18:17   ` Matthew Wilcox
2021-01-18 18:31     ` Christoph Hellwig
2021-01-18 19:20       ` Matthew Wilcox
2021-01-18 23:52         ` Damien Le Moal [this message]
2021-01-19  6:12           ` Christoph Hellwig

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=BL0PR04MB6514A4BFE2EA5AE59795E586E7A40@BL0PR04MB6514.namprd04.prod.outlook.com \
    --to=damien.lemoal@wdc.com \
    --cc=axboe@kernel.dk \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=willy@infradead.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.