linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>,
	linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Hugh Dickins <hughd@google.com>,
	William Kucharski <william.kucharski@oracle.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/7] mm: Add an 'end' parameter to find_get_entries
Date: Fri, 21 Aug 2020 20:06:29 +0200	[thread overview]
Message-ID: <20200821180629.GF3432@quack2.suse.cz> (raw)
In-Reply-To: <20200821163306.GW17456@casper.infradead.org>

[-- Attachment #1: Type: text/plain, Size: 1828 bytes --]

On Fri 21-08-20 17:33:06, Matthew Wilcox wrote:
> On Fri, Aug 21, 2020 at 06:07:59PM +0200, Jan Kara wrote:
> > On Wed 19-08-20 16:05:51, Matthew Wilcox (Oracle) wrote:
> > > This simplifies the callers and leads to a more efficient implementation
> > > since the XArray has this functionality already.
> > > 
> > > Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
> > 
> > The patch looks good to me. Just I'd note that you could drop some:
> > 
> > 	if (index >= end)
> > 		break;
> > 
> > checks in shmem_undo_range() as well.
> 
> Oh yes, missed a couple ;-)  Thanks, I'll add.
> 
> > In the past I was considering moving find_get_entries() to the same API as
> > find_get_pages_range() has (which is essentially what you do now, but I
> > also had 'start' to be a pgoff_t * so that we can return there where the
> > iteration ended in the range). But in the end I've decided the churn is not
> > worth the few removed lines and didn't push the patch in the end. What you
> > did in this patch seems to be a reasonable middle-ground :)
> 
> I did look at that, but since we're returning the indices, we don't _need_
> to update the index here.
> 
> I have some other ideas for this family of interfaces, but I'm trying
> to get the THP work off my plate before getting distracted by that ;-)

I have one thing which I wanted to do for a long time but never got to it.
IMHO the pagevec abstraction makes the loops unnecessarily complex. I'd
rather have helpers like:

for_each_mapping_page(mapping, page, start, end)

or

for_each_mapping_entry(mapping, entry, index, start, end)

and hide all the pagevec magic inside those. And it's even not that hard to
do including the handling of premature exit from the loop - sample
userspace code is attached...

									Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

[-- Attachment #2: pvec_looping.c --]
[-- Type: text/x-c, Size: 1401 bytes --]

#include <stdio.h>

#define PAGEVEC_SIZE 15

struct pagevec {
	unsigned char nr;
	int vals[PAGEVEC_SIZE];
};

struct pagevec_iter {
	unsigned char idx;
	int last_index;
	struct pagevec pvec;
};

void pagevec_release(struct pagevec *pvec)
{
	int i;

	for (i = 0; i < pvec->nr; i++)
		printf("Freeing val %d\n", pvec->vals[i]);
	pvec->nr = 0;
}

int pagevec_lookup(struct pagevec *pvec, void *mapping, int *start, int end)
{
	int i;

	for (i = 0; i < PAGEVEC_SIZE && *start < 29; i++) {
		pvec->vals[pvec->nr++] = 100 + *start;
		(*start)++;
	}
	return pvec->nr;
}

static inline int get_next_pvec_val(struct pagevec_iter *pvec_i, void *mapping,
				    int end)
{
	if (pvec_i->idx >= pvec_i->pvec.nr) {
		pagevec_release(&pvec_i->pvec);
		if (!pagevec_lookup(&pvec_i->pvec, mapping, &pvec_i->last_index,
				    end))
			return 0;
		pvec_i->idx = 0;
	}
	return pvec_i->pvec.vals[pvec_i->idx++];
}

void pagevec_release_iter(struct pagevec_iter *pvec_i)
{
	pagevec_release(&pvec_i->pvec);
}

#define for_each_page(mapping, page, start, end)			\
	for (struct pagevec_iter pvec_i					\
		__attribute__ ((cleanup (pagevec_release_iter))) = {	\
			.idx = 0, .last_index = start, .pvec = { .nr = 0 } }; \
	     (page = get_next_pvec_val(&pvec_i, mapping, end));)

int main(void)
{
	int page;

	for_each_page(NULL, page, 5, 32) {
		printf("Seeing val %d\n", page);
		if (page > 122)
			break;
	}
	return 0;
}

  reply	other threads:[~2020-08-21 18:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-19 15:05 [PATCH 0/7] Overhaul find_get_entries and pagevec_lookup_entries Matthew Wilcox (Oracle)
2020-08-19 15:05 ` [PATCH 1/7] mm: Use pagevec_lookup in shmem_unlock_mapping Matthew Wilcox (Oracle)
2020-08-21 15:53   ` Jan Kara
2020-08-19 15:05 ` [PATCH 2/7] mm: Rewrite shmem_seek_hole_data Matthew Wilcox (Oracle)
2020-08-20 16:45   ` Mike Rapoport
2020-08-20 19:04     ` Matthew Wilcox
2020-08-19 15:05 ` [PATCH 3/7] mm: Add an 'end' parameter to find_get_entries Matthew Wilcox (Oracle)
2020-08-20 16:47   ` Mike Rapoport
2020-08-21 16:07   ` Jan Kara
2020-08-21 16:33     ` Matthew Wilcox
2020-08-21 18:06       ` Jan Kara [this message]
2020-08-19 15:05 ` [PATCH 4/7] mm: Add an 'end' parameter to pagevec_lookup_entries Matthew Wilcox (Oracle)
2020-08-24 16:09   ` Jan Kara
2020-08-19 15:05 ` [PATCH 5/7] mm: Remove nr_entries parameter from pagevec_lookup_entries Matthew Wilcox (Oracle)
2020-08-24 16:10   ` Jan Kara
2020-08-19 15:05 ` [PATCH 6/7] mm: Pass pvec directly to find_get_entries Matthew Wilcox (Oracle)
2020-08-24 16:16   ` Jan Kara
2020-08-24 17:36     ` Matthew Wilcox
2020-08-25 12:33       ` Jan Kara
2020-08-25 13:28         ` Matthew Wilcox
2020-08-25 15:24           ` Jan Kara
2020-08-25 16:23           ` Johannes Weiner
2020-08-19 15:05 ` [PATCH 7/7] mm: Remove pagevec_lookup_entries Matthew Wilcox (Oracle)
2020-08-22  2:34 ` [PATCH 0/7] Overhaul find_get_entries and pagevec_lookup_entries William Kucharski

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=20200821180629.GF3432@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=william.kucharski@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).