Page flags, can we free up space ?
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
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
Quoted 4 lines · Jerome Glisse
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 would just stop putting node/zone number into the flags. These could be all handled with a small perfect hash table, like the original x86_64 port did, which should be quite cheap to look up. Then there should be enough bits for everyone again.
-Andi
Quoted 10 lines · Andi Kleen
Quoted 4 lines · Jerome Glisse
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 would just stop putting node/zone number into the flags. These could be all handled with a small perfect hash table, like the original
x86_64port did, which should be quite cheap to look up. Then there should be enough bits for everyone again.
Definitly something i will look into, i was scare to remove those.
Cheers,
Jérôme
Quoted 32 lines · Jerome Glisse
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_unevictableOn top of which you can add the page anonymous flag (anonymous or share memory)
PG_anon // does not exist, lower bit of page->mappingAnd also the movable flag (which alias with KSM)
PG_movable // does not exist, lower bit of page->mappingSo 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.
Quoted 6 lines
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 :)
Explicitly adding Matthew on Cc as I am pretty sure he has been working in this area.
Signature · 1 line
Mike Kravetz
Quoted 10 lines · Jerome Glisse
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
Quoted 6 lines
On top of which you can add the page anonymous flag (anonymous or share memory)
PG_anon // does not exist, lower bit of page->mappingAnd 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.
Quoted 26 lines
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
Signature · 3 lines
Thanks, David / dhildenb