linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Matthew Wilcox <willy@infradead.org>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	linux-mm@kvack.org, kernel-janitors@vger.kernel.org,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [Linux-kernel-mentees] [PROJECT] clean up swapcache use of struct page
Date: Mon, 19 Aug 2019 18:17:02 -0600	[thread overview]
Message-ID: <f69a2e2e-ec21-efd6-4787-59f1c77885b3@linuxfoundation.org> (raw)
In-Reply-To: <20190819235456.GA9657@bombadil.infradead.org>

Hi Matthew,

On 8/19/19 5:54 PM, Matthew Wilcox wrote:
> 
> This would be a good project for someone with a little experience and
> a lot of attention to detail.
> 
> The struct page is probably the most abused data structure in the kernel,
> and for good reason.  But some of the abuse is unnecessary ... a mere
> historical accident that would be better fixed.
> 
> Page cache pages use page->mapping and page->index to indicate which file
> the page belongs to and where in that file it is.  page->private may be
> used by the filesystem for its own purposes (eg buffer heads).
> 
> Anonymous pages use page->mapping to point to the anon VMA they belong
> to and page->index to record the offset within the VMA.  Then, if they
> are also part of the swap cache, they use page->private to record both
> the offset within the swap device and the index of the page within the
> swap device.
> 
> Then we get abominations like:
> 
> static inline pgoff_t page_index(struct page *page)
> {
>          if (unlikely(PageSwapCache(page)))
>                  return __page_file_index(page);
>          return page->index;
> }
> 
> My modest proposal for deleting the first two lines of that function is
> to first switch the uses of page->private and page->index for anonymous
> pages.  Then move the swp_type() back from page->index to page->private
> again [1].
> 
> I am willing to review patches and provide feedback.  I can go into more
> detail about how I think this should be tackled if there's interest.
> Also, if you know more than I do about the MM and think this is a bad
> idea, please do say ;-)
> 

I will be happy to add it to the project list for Spring session.

We can work together to come up with a task list to get the candidates
up to speed during the application process period which starts on Nov 1st.

> This is going to be a tough project because there are a lot of
> rarely-tested paths which directly reference (eg) page->index, and they
> might be talking about a page cache page or a swap page.  This is not
> a simple Coccinelle script.

Yes mm isn't an easy area especially for new developers. We can work
together to come up with a task list to get the candidates up to speed
during the application process period which starts on Nov 1st.

> 
> [1] We have enough bits to do this; on a 32-bit machine, we can at most
> have a VMA which covers 4GB memory and with a 4kB page size, that's only
> 20 bits needed to encode all possible offsets within a VMA).

That being said, I will wait for other mm experts weigh in.

thanks,
-- Shuah


      reply	other threads:[~2019-08-20  0:17 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-19 23:54 Matthew Wilcox
2019-08-20  0:17 ` Shuah Khan [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=f69a2e2e-ec21-efd6-4787-59f1c77885b3@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox