All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@linux.dev>
To: Matthew Wilcox <willy@infradead.org>
Cc: "Pankaj Raghav (Samsung)" <kernel@pankajraghav.com>,
	 linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org,
	djwong@kernel.org, mcgrof@kernel.org,  linux-mm@kvack.org,
	hare@suse.de, david@fromorbit.com, akpm@linux-foundation.org,
	 gost.dev@samsung.com, linux-kernel@vger.kernel.org,
	chandan.babu@oracle.com,  Pankaj Raghav <p.raghav@samsung.com>
Subject: Re: [PATCH v2 03/13] filemap: align the index to mapping_min_order in the page cache
Date: Fri, 1 Mar 2024 15:04:33 -0500	[thread overview]
Message-ID: <c5rw63nyg2tdkgeuvriu74jjv2vszy2luorhmv3gb4uz2z4msz@2ktshazjwc2n> (raw)
In-Reply-To: <ZeIr_2fiEpWLgmsv@casper.infradead.org>

On Fri, Mar 01, 2024 at 07:26:55PM +0000, Matthew Wilcox wrote:
> On Fri, Mar 01, 2024 at 05:44:34PM +0100, Pankaj Raghav (Samsung) wrote:
> > +#define DEFINE_READAHEAD_ALIGNED(ractl, f, r, m, i)			\
> > +	struct readahead_control ractl = {				\
> > +		.file = f,						\
> > +		.mapping = m,						\
> > +		.ra = r,						\
> > +		._index = mapping_align_start_index(m, i),		\
> > +	}
> 
> My point was that you didn't need to do any of this.
> 
> Look, I've tried to give constructive review, but I feel like I'm going
> to have to be blunt.  There is no evidence of design or understanding
> in these patches or their commit messages.  You don't have a coherent
> message about "These things have to be aligned; these things can be at
> arbitrary alignment".  If you have thought about it, it doesn't show.

Don't you think you might be going off a bit much? I looked over these
patches after we talked privately, and they looked pretty sensible to
me...

Yes, we _always_ want more thorough commit messages that properly
explain the motivations for changes, but in my experience that's the
thing that takes the longest to learn how to do well as an engineer...
ease up abit.

> So, let's start off: Is the index in ractl aligned or not, and why do
> you believe that's the right approach?  And review each of the patches
> in this series with the answer to that question in mind because you are
> currently inconsistent.

^ this is a real point though, DEFINE_READAHEAD_ALIGNED() feels off to
me.

  reply	other threads:[~2024-03-01 20:04 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-01 16:44 [PATCH v2 00/13] enable bs > ps in XFS Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 01/13] mm: Support order-1 folios in the page cache Pankaj Raghav (Samsung)
2024-03-01 17:08   ` Hannes Reinecke
2024-03-01 16:44 ` [PATCH v2 02/13] fs: Allow fine-grained control of folio sizes Pankaj Raghav (Samsung)
2024-03-01 17:09   ` Hannes Reinecke
2024-03-01 16:44 ` [PATCH v2 03/13] filemap: align the index to mapping_min_order in the page cache Pankaj Raghav (Samsung)
2024-03-01 19:26   ` Matthew Wilcox
2024-03-01 20:04     ` Kent Overstreet [this message]
2024-03-04 15:38       ` Pankaj Raghav (Samsung)
2024-03-04 15:36     ` Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 04/13] filemap: use mapping_min_order while allocating folios Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 05/13] readahead: round up file_ra_state->ra_pages to mapping_min_nrpages Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 06/13] readahead: align index to mapping_min_order in ondemand_ra and force_ra Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 07/13] readahead: rework loop in page_cache_ra_unbounded() Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 08/13] readahead: allocate folios with mapping_min_order in ra_(unbounded|order) Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 09/13] mm: do not split a folio if it has minimum folio order requirement Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 10/13] iomap: fix iomap_dio_zero() for fs bs > system page size Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 11/13] xfs: expose block size in stat Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 12/13] xfs: make the calculation generic in xfs_sb_validate_fsb_count() Pankaj Raghav (Samsung)
2024-03-01 16:44 ` [PATCH v2 13/13] xfs: enable block size larger than page size support Pankaj Raghav (Samsung)

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=c5rw63nyg2tdkgeuvriu74jjv2vszy2luorhmv3gb4uz2z4msz@2ktshazjwc2n \
    --to=kent.overstreet@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=chandan.babu@oracle.com \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=gost.dev@samsung.com \
    --cc=hare@suse.de \
    --cc=kernel@pankajraghav.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=p.raghav@samsung.com \
    --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.