From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/3] xfs: add kmem_alloc_io()
Date: Thu, 22 Aug 2019 10:31:32 +1000 [thread overview]
Message-ID: <20190822003131.GR1119@dread.disaster.area> (raw)
In-Reply-To: <20190821232440.GB24904@infradead.org>
On Wed, Aug 21, 2019 at 04:24:40PM -0700, Christoph Hellwig wrote:
> > +
> > +/*
> > + * __vmalloc() will allocate data pages and auxillary structures (e.g.
> > + * pagetables) with GFP_KERNEL, yet we may be under GFP_NOFS context here. Hence
> > + * we need to tell memory reclaim that we are in such a context via
> > + * PF_MEMALLOC_NOFS to prevent memory reclaim re-entering the filesystem here
> > + * and potentially deadlocking.
> > + */
>
> Btw, I think we should eventually kill off KM_NOFS and just use
> PF_MEMALLOC_NOFS in XFS, as the interface makes so much more sense.
> But that's something for the future.
Yeah, and it's not quite as simple as just using PF_MEMALLOC_NOFS
at high levels - we'll still need to annotate callers that use KM_NOFS
to avoid lockdep false positives. i.e. any code that can be called from
GFP_KERNEL and reclaim context will throw false positives from
lockdep if we don't annotate tehm correctly....
> > +/*
> > + * Same as kmem_alloc_large, except we guarantee a 512 byte aligned buffer is
> > + * returned. vmalloc always returns an aligned region.
> > + */
> > +void *
> > +kmem_alloc_io(size_t size, xfs_km_flags_t flags)
> > +{
> > + void *ptr;
> > +
> > + trace_kmem_alloc_io(size, flags, _RET_IP_);
> > +
> > + ptr = kmem_alloc(size, flags | KM_MAYFAIL);
> > + if (ptr) {
> > + if (!((long)ptr & 511))
>
> Please use unsigned long (or uintptr_t if you want to be fancy),
> and (SECTOR_SIZE - 1).
Already changed it to uintptr_t when I did...
>
> As said elsewhere if we want to be fancy we should probably pass a
> request queue or something pointing to it.
.... this. Well, not exactly this - I pass in the alignment required
as an int, and the callers get it from the request queue....
> But then again I don't think
> it really matters much, it would save us the reallocation with slub debug
> for a bunch of scsi adapters that support dword aligned I/O. But last
> least the interface would be a little more obvious.
Yup, just smoke testing it now before I resend.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2019-08-22 0:32 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-21 8:38 [PATCH 0/3] xfs: avoid IO issues unaligned memory allocation Dave Chinner
2019-08-21 8:38 ` [PATCH 1/3] xfs: add kmem allocation trace points Dave Chinner
2019-08-21 13:34 ` Brian Foster
2019-08-21 23:20 ` Christoph Hellwig
2019-08-21 8:38 ` [PATCH 2/3] xfs: add kmem_alloc_io() Dave Chinner
2019-08-21 13:35 ` Brian Foster
2019-08-21 15:08 ` Darrick J. Wong
2019-08-21 21:24 ` Dave Chinner
2019-08-21 15:23 ` Eric Sandeen
2019-08-21 21:14 ` Dave Chinner
2019-08-22 13:40 ` Brian Foster
2019-08-22 22:39 ` Dave Chinner
2019-08-23 12:10 ` Brian Foster
2019-08-21 23:24 ` Christoph Hellwig
2019-08-22 0:31 ` Dave Chinner [this message]
2019-08-22 7:59 ` Christoph Hellwig
2019-08-22 8:51 ` Peter Zijlstra
2019-08-22 9:10 ` Peter Zijlstra
2019-08-22 10:14 ` Dave Chinner
2019-08-22 11:14 ` Vlastimil Babka
2019-08-22 12:07 ` Dave Chinner
2019-08-22 12:19 ` Vlastimil Babka
2019-08-22 13:17 ` Dave Chinner
2019-08-22 14:26 ` Vlastimil Babka
2019-08-26 12:21 ` Michal Hocko
2019-08-21 8:38 ` [PATCH 3/3] xfs: alignment check bio buffers Dave Chinner
2019-08-21 13:39 ` Brian Foster
2019-08-21 21:39 ` Dave Chinner
2019-08-22 13:47 ` Brian Foster
2019-08-22 23:03 ` Dave Chinner
2019-08-23 12:33 ` Brian Foster
2019-08-21 23:30 ` Christoph Hellwig
2019-08-22 0:44 ` Dave Chinner
2019-08-21 23:29 ` Christoph Hellwig
2019-08-22 0:37 ` Dave Chinner
2019-08-22 8:03 ` Christoph Hellwig
2019-08-22 10:17 ` Dave Chinner
2019-08-22 2:50 ` Ming Lei
2019-08-22 4:49 ` Dave Chinner
2019-08-22 7:23 ` Ming Lei
2019-08-22 8:08 ` Christoph Hellwig
2019-08-22 10:20 ` Ming Lei
2019-08-23 0:14 ` Christoph Hellwig
2019-08-23 1:19 ` Ming Lei
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=20190822003131.GR1119@dread.disaster.area \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-xfs@vger.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.