All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Begunkov <asml.silence@gmail.com>
To: Christoph Hellwig <hch@lst.de>
Cc: Anuj Gupta <anuj1072538@gmail.com>,
	djwong@kernel.org, cem@kernel.org, brauner@kernel.org,
	axboe@kernel.dk, linux-block@vger.kernel.org,
	linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	joshi.k@samsung.com, anuj20.g@samsung.com, nj.shetty@samsung.com
Subject: Re: [RFC 0/4] fs: support dma-buf backed direct I/O
Date: Thu, 29 Oct 2026 11:34:07 +0000	[thread overview]
Message-ID: <69f1290c-1650-4ce4-bc0f-e8a3c03a5d14@gmail.com> (raw)
In-Reply-To: <20261028162900.GA22640@lst.de>

On 10/28/26 16:29, Christoph Hellwig wrote:
> On Sun, Oct 18, 2026 at 11:18:27PM +0100, Pavel Begunkov wrote:
>>   	file_ref_t			f_ref;
>>   	/* --- cacheline 3 boundary (192 bytes) --- */
>> +
>> +	/*
>> +	 * A tag representing the underlying subsystem for dma-buf I/O.
>> +	 * See struct dma_buf_io_ctx::importer_tag.
>> +	 */
>> +	unsigned long			f_dma_io_tag;
>>   } __randomize_layout
> 
> Growing strut file into a new cacheline just for dmabufs is a no-go..

I didn't check last time but there is space to spare. Maybe I don't
know about all production enabled options growing mutexes.

struct file {
         spinlock_t                 f_lock __attribute__((__aligned__(4))); /*     0     4 */
         fmode_t                    f_mode;               /*     4     4 */
         const struct file_operations  * f_op;            /*     8     8 */
         struct address_space *     f_mapping;            /*    16     8 */
         void *                     private_data;         /*    24     8 */
         struct inode *             f_inode;              /*    32     8 */
         unsigned int               f_flags;              /*    40     4 */
         unsigned int               f_iocb_flags;         /*    44     4 */
         const struct cred  *       f_cred;               /*    48     8 */
         struct fown_struct *       f_owner;              /*    56     8 */
         /* --- cacheline 1 boundary (64 bytes) --- */
         union {
                 const struct path  f_path;               /*    64    16 */
                 struct path        __f_path;             /*    64    16 */
         };                                               /*    64    16 */
         union {
                 struct mutex       f_pos_lock __attribute__((__aligned__(8))); /*    80    24 */
                 u64                f_pipe;               /*    80     8 */
         } __attribute__((__aligned__(8)));               /*    80    24 */
         loff_t                     f_pos;                /*   104     8 */
         void *                     f_security;           /*   112     8 */
         errseq_t                   f_wb_err;             /*   120     4 */
         errseq_t                   f_sb_err;             /*   124     4 */
         /* --- cacheline 2 boundary (128 bytes) --- */
         struct hlist_head *        f_ep;                 /*   128     8 */
         union {
                 struct callback_head f_task_work __attribute__((__aligned__(8))); /*   136    16 */
                 struct llist_node  f_llist;              /*   136     8 */
                 struct file_ra_state f_ra;               /*   136    32 */
                 freeptr_t          f_freeptr;            /*   136     8 */
         } __attribute__((__aligned__(8)));               /*   136    32 */
         file_ref_t                 f_ref;                /*   168     8 */

         /* size: 176, cachelines: 3, members: 19 */
         /* forced alignments: 3 */
         /* last cacheline: 48 bytes */
} __attribute__((__aligned__(8)));

  
> Also note that a file can be placed on multiple block devices when
> using RAID or just btrfs placements (not sure about f2fs).

Filesystems should set it to a super block or something similar.
It's "unsigned long" for that exact reason. Shouldn't be a problem
for md either.

-- 
Pavel Begunkov


      reply	other threads:[~2026-10-29 11:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-16  9:19 [RFC 0/4] fs: support dma-buf backed direct I/O Anuj Gupta
2026-10-16  9:19 ` [RFC 1/4] block: factor out bdev_init_dma_buf_io_ctx() Anuj Gupta
2026-10-16  9:23   ` Christoph Hellwig
2026-10-16  9:19 ` [RFC 2/4] block: refuse a dma-buf bio for a disk the buffer was not registered on Anuj Gupta
2026-10-16  9:24   ` Christoph Hellwig
2026-10-21 15:12   ` Pavel Begunkov
2026-10-22 13:00     ` Nitesh Shetty
2026-10-16  9:19 ` [RFC 3/4] iomap: add dma-buf direct I/O guards and registration helper Anuj Gupta
2026-10-16  9:26   ` Christoph Hellwig
2026-10-16  9:19 ` [RFC 4/4] xfs: support dma-buf registered buffers for direct I/O Anuj Gupta
2026-10-16  9:28   ` Christoph Hellwig
2026-10-17 18:19     ` Kanchan Joshi
2026-10-18 22:28     ` Pavel Begunkov
2026-10-19 10:29     ` Anuj gupta
2026-10-17 22:54 ` [RFC 0/4] fs: support dma-buf backed " shinichiro.kawasaki
2026-10-18 13:32   ` Shin'ichiro Kawasaki
2026-10-18 22:18 ` Pavel Begunkov
2026-10-28 16:29   ` Christoph Hellwig
2026-10-29 11:34     ` Pavel Begunkov [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=69f1290c-1650-4ce4-bc0f-e8a3c03a5d14@gmail.com \
    --to=asml.silence@gmail.com \
    --cc=anuj1072538@gmail.com \
    --cc=anuj20.g@samsung.com \
    --cc=axboe@kernel.dk \
    --cc=brauner@kernel.org \
    --cc=cem@kernel.org \
    --cc=djwong@kernel.org \
    --cc=hch@lst.de \
    --cc=joshi.k@samsung.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=nj.shetty@samsung.com \
    /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.