On Thu, Jun 20, 2024 at 09:18:58AM -0600, Jens Axboe wrote:
> On 6/20/24 9:15 AM, Matthew Wilcox wrote:
> > On Thu, Jun 20, 2024 at 08:56:39AM -0600, Jens Axboe wrote:
> >> On 6/20/24 8:49 AM, Matthew Wilcox wrote:
> >>> On Thu, Jun 20, 2024 at 10:16:02AM -0400, Kent Overstreet wrote:
> >>> I'm more sympathetic to "lets relax the alignment requirements", since
> >>> most IO devices actually can do IO to arbitrary boundaries (or at least
> >>> reasonable boundaries, eg cacheline alignment or 4-byte alignment).
> >>> The 512 byte alignment doesn't seem particularly rooted in any hardware
> >>> restrictions.
> >>
> >> We already did, based on real world use cases to avoid copies just
> >> because the memory wasn't aligned on a sector size boundary. It's
> >> perfectly valid now to do:
> >>
> >> struct queue_limits lim {
> >> .dma_alignment = 3,
> >> };
> >>
> >> disk = blk_mq_alloc_disk(&tag_set, &lim, NULL);
> >>
> >> and have O_DIRECT with a 32-bit memory alignment work just fine, where
> >> before it would EINVAL. The sector size memory alignment thing has
> >> always been odd and never rooted in anything other than "oh let's just
> >> require the whole combination of size/disk offset/alignment to be sector
> >> based".
> >
> > Oh, cool! https://man7.org/linux/man-pages/man2/open.2.html
> > doesn't know about this yet; is anyone working on updating it?
>
> Probably not... At least we do have STATX_DIOALIGN which can be used to
> figure out what the alignment is, but I don't recall if any man date
> updates got done. Keith may remember, CC'ed.
The man page already recommends statx if available, which tells you
everything you need to know about your device's direct io alignment
requirements. The man only suggests block size alignment for older
kernels, so I think it's fine as-is, no?
You can also query the queue's "dma_alignment" sysfs attribute.
