All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Price <steven.price@arm.com>
To: Matthew Wilcox <willy@infradead.org>,
	Christoph Hellwig <hch@infradead.org>
Cc: "Linus Torvalds" <torvalds@linux-foundation.org>,
	"Thomas Hellström (VMware)" <thomas@shipmail.org>,
	"Dave Airlie" <airlied@gmail.com>,
	"Thomas Hellstrom" <thellstrom@vmware.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	LKML <linux-kernel@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Jerome Glisse" <jglisse@redhat.com>,
	"Jason Gunthorpe" <jgg@mellanox.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: drm pull for v5.3-rc1
Date: Wed, 7 Aug 2019 15:30:38 +0100	[thread overview]
Message-ID: <62cbe523-e8a4-cdfd-90c2-80260cefa5de@arm.com> (raw)
In-Reply-To: <20190807141517.GA5482@bombadil.infradead.org>

On 07/08/2019 15:15, Matthew Wilcox wrote:
> On Tue, Aug 06, 2019 at 11:40:00PM -0700, Christoph Hellwig wrote:
>> On Tue, Aug 06, 2019 at 12:09:38PM -0700, Matthew Wilcox wrote:
>>> Has anyone looked at turning the interface inside-out?  ie something like:
>>>
>>> 	struct mm_walk_state state = { .mm = mm, .start = start, .end = end, };
>>>
>>> 	for_each_page_range(&state, page) {
>>> 		... do something with page ...
>>> 	}
>>>
>>> with appropriate macrology along the lines of:
>>>
>>> #define for_each_page_range(state, page)				\
>>> 	while ((page = page_range_walk_next(state)))
>>>
>>> Then you don't need to package anything up into structs that are shared
>>> between the caller and the iterated function.
>>
>> I'm not an all that huge fan of super magic macro loops.  But in this
>> case I don't see how it could even work, as we get special callbacks
>> for huge pages and holes, and people are trying to add a few more ops
>> as well.
> 
> We could have bits in the mm_walk_state which indicate what things to return
> and what things to skip.  We could (and probably should) also use different
> iterator names if people actually want to iterate different things.  eg
> for_each_pte_range(&state, pte) as well as for_each_page_range().
> 

The iterator approach could be awkward for the likes of my generic
ptdump implementation[1]. It would require an iterator which returns all
levels and allows skipping levels when required (to prevent KASAN
slowing things down too much). So something like:

start_walk_range(&state);
for_each_page_range(&state, page) {
	switch(page->level) {
	case PTE:
		...
	case PMD:
		if (...)
			skip_pmd(&state);
		...
	case HOLE:
		....
	...
	}
}
end_walk_range(&state);

It seems a little fragile - e.g. we wouldn't (easily) get type checking
that you are actually treating a PTE as a pte_t. The state mutators like
skip_pmd() also seem a bit clumsy.

Steve

[1]
https://lore.kernel.org/lkml/20190731154603.41797-20-steven.price@arm.com/

  reply	other threads:[~2019-08-07 14:30 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAPM=9tzJQ+26n_Df1eBPG1A=tXf4xNuVEjbG3aZj-aqYQ9nnAg@mail.gmail.com>
2019-07-15  6:59 ` Re:DRM pull for v5.3-rc1 Dave Airlie
2019-07-15 12:29   ` DRM " Jason Gunthorpe
2019-07-15 13:21     ` Stephen Rothwell
2019-07-15 14:19     ` Daniel Vetter
2019-07-15 14:19       ` Daniel Vetter
2019-07-15 15:04       ` Jason Gunthorpe
2019-07-15 17:53         ` Daniel Vetter
2019-07-15 17:57           ` Jason Gunthorpe
2019-07-15 18:06             ` Daniel Vetter
2019-07-15 18:06               ` Daniel Vetter
2019-07-15 18:16     ` Linus Torvalds
2019-07-15 19:00       ` Linus Torvalds
2019-07-15 19:00         ` Linus Torvalds
2019-07-15 19:17       ` Jason Gunthorpe
2019-07-15 19:31         ` Linus Torvalds
2019-07-15  7:08 ` drm " Dave Airlie
2019-07-15  7:08   ` Dave Airlie
2019-07-15 12:16   ` Daniel Vetter
2019-07-15 17:37   ` Linus Torvalds
2019-07-15 18:00     ` Linus Torvalds
2019-07-15 18:29       ` Dave Airlie
2019-07-15 18:29         ` Dave Airlie
2019-07-15 18:37         ` Linus Torvalds
2019-07-15 19:35       ` Thomas Hellström (VMware)
2019-07-15 19:35         ` Thomas Hellström (VMware)
2019-07-15 20:07         ` Linus Torvalds
2019-07-15 22:17           ` Linus Torvalds
2019-08-06  7:38             ` Christoph Hellwig
2019-08-06  7:38               ` Christoph Hellwig
2019-08-06  7:40               ` Christoph Hellwig
2019-08-06 18:50               ` Linus Torvalds
2019-08-06 18:50                 ` Linus Torvalds
2019-08-06 19:09                 ` Matthew Wilcox
2019-08-07  6:40                   ` Christoph Hellwig
2019-08-07 14:15                     ` Matthew Wilcox
2019-08-07 14:30                       ` Steven Price [this message]
2019-08-07 14:56                         ` Matthew Wilcox
2019-08-07 15:32                           ` Steven Price
2019-08-07 15:55                             ` Matthew Wilcox
2019-08-07 19:16                     ` Linus Torvalds
2019-08-07  6:38                 ` Christoph Hellwig
2019-07-15 18:27     ` Dave Airlie

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=62cbe523-e8a4-cdfd-90c2-80260cefa5de@arm.com \
    --to=steven.price@arm.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hch@infradead.org \
    --cc=jgg@mellanox.com \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=thellstrom@vmware.com \
    --cc=thomas@shipmail.org \
    --cc=torvalds@linux-foundation.org \
    --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.