linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Jerome Glisse <jglisse@redhat.com>, lsf-pc@lists.linux-foundation.org
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Michal Hocko <mhocko@kernel.org>
Subject: Re: [LSF/MM TOPIC] Page flags, can we free up space ?
Date: Wed, 30 Jan 2019 12:51:57 +0100	[thread overview]
Message-ID: <596246f1-5ebc-7088-e303-00983984e864@redhat.com> (raw)
In-Reply-To: <20190122201744.GA3939@redhat.com>

On 22.01.19 21:17, Jerome Glisse wrote:
> So lattely i have been looking at page flags and we are using 6 flags
> for memory reclaim and compaction:
> 
>     PG_referenced
>     PG_lru
>     PG_active
>     PG_workingset
>     PG_reclaim
>     PG_unevictable
> 
> On top of which you can add the page anonymous flag (anonymous or
> share memory)
>     PG_anon // does not exist, lower bit of page->mapping
> 
> And also the movable flag (which alias with KSM)
>     PG_movable // does not exist, lower bit of page->mapping


I would really like to see an easier way to spot if a page is movable.

__PageMovable() can produce way to many false positives.

movable will usually not be paired with other flags you mentioned as of now.

If many of these flags are not used in combination, we could merge some
of the flags into a number field. Valid combinations would get a number
assigned.

To keep it simple, only flags that are completely exclusive might be a
candidate. But not sure if we really have many of these.

> 
> 
> So i would like to explore if there is a way to express the same amount
> of information with less bits. My methodology is to exhaustively list
> all the possible states (valid combination of above flags) and then to
> see how we change from one state to another (what event trigger the change
> like mlock(), page being referenced, ...) and under which rules (ie do we
> hold the page lock, zone lock, ...).
> 
> My hope is that there might be someway to use less bits to express the
> same thing. I am doing this because for my work on generic page write
> protection (ie KSM for file back page) which i talk about last year and
> want to talk about again ;) I will need to unalias the movable bit from
> KSM bit.
> 
> 
> Right now this is more a temptative ie i do not know if i will succeed,
> in any case i can report on failure or success and discuss my finding to
> get people opinions on the matter.
> 
> 
> I think everyone interested in mm will be interested in this topic :)
> 
> Cheers,
> Jérôme
> 


-- 

Thanks,

David / dhildenb


      parent reply	other threads:[~2019-01-30 11:52 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22 20:17 Jerome Glisse
2019-01-22 21:44 ` Andi Kleen
2019-01-22 21:44   ` Andi Kleen
2019-01-22 23:52   ` Jerome Glisse
2019-01-23  1:56 ` Mike Kravetz
2019-01-30 11:51 ` David Hildenbrand [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=596246f1-5ebc-7088-e303-00983984e864@redhat.com \
    --to=david@redhat.com \
    --cc=jglisse@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=mhocko@kernel.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