[LSF/MM TOPIC] [ATTEND] mm track: RAM utilization and page replacement topics

[LSF/MM TOPIC] [ATTEND] mm track: RAM utilization and page replacement topics

[Dan Magenheimer]

Some (related) topics proposed for the MM track:

1) Optimizing the utilization of RAM as a resource, i.e. how do we teach the
   kernel to NOT use all RAM when it doesn't really "need" it.  See
   http://lwn.net/Articles/475681/ (or if you don't want to read the whole
   article, start with "Interestingly, ..." four paragraphs from the end).

2) RAMster now exists and works... where are the holes and what next?
   http://marc.info/?l=linux-mm&m=132768187222840&w=2 

3) Next steps in the page replacement algorithm:
	a) WasActive https://lkml.org/lkml/2012/1/25/300 
	b) readahead http://marc.info/?l=linux-scsi&m=132750980203130 

4) Remaining impediments for merging frontswap

5) Page flags and 64-bit-only... what are the tradeoffs?

Thanks,
Dan Magenheimer
"Mr. Tmem"
http://lwn.net/Articles/454795/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] [ATTEND] mm track: RAM utilization and page replacement topics

[Hugh Dickins]

On Fri, 27 Jan 2012, Dan Magenheimer wrote:
> Some (related) topics proposed for the MM track:
> 
> 1) Optimizing the utilization of RAM as a resource, i.e. how do we teach the
>    kernel to NOT use all RAM when it doesn't really "need" it.  See
>    http://lwn.net/Articles/475681/ (or if you don't want to read the whole
>    article, start with "Interestingly, ..." four paragraphs from the end).
> 
> 2) RAMster now exists and works... where are the holes and what next?
>    http://marc.info/?l=linux-mm&m=132768187222840&w=2 
> 
> 3) Next steps in the page replacement algorithm:
> 	a) WasActive https://lkml.org/lkml/2012/1/25/300 
> 	b) readahead http://marc.info/?l=linux-scsi&m=132750980203130 
> 
> 4) Remaining impediments for merging frontswap
> 
> 5) Page flags and 64-bit-only... what are the tradeoffs?

Yes, this last one is something I want to discuss too.  If page_cgroup
hadn't grown so small, I'd be suggesting to squeeze some more flag bits
(or better, the node/zone info) into the 32-bit struct page lru pointers.

But with page_cgroup now ready to fit into the 64-bit struct page (which
contains an empty field from SLUB's alignment demands), it might - might -
be time to enlarge the 32-bit struct page slightly.

Hugh

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Re: [LSF/MM TOPIC] [ATTEND] mm track: RAM utilization and page replacement topics

[Rik van Riel]

On 01/27/2012 12:19 PM, Dan Magenheimer wrote:
> Some (related) topics proposed for the MM track:
>
> 1) Optimizing the utilization of RAM as a resource, i.e. how do we teach the
>     kernel to NOT use all RAM when it doesn't really "need" it.  See
>     http://lwn.net/Articles/475681/ (or if you don't want to read the whole
>     article, start with "Interestingly, ..." four paragraphs from the end).
>
> 2) RAMster now exists and works... where are the holes and what next?
>     http://marc.info/?l=linux-mm&m=132768187222840&w=2
>
> 3) Next steps in the page replacement algorithm:
> 	a) WasActive https://lkml.org/lkml/2012/1/25/300
> 	b) readahead http://marc.info/?l=linux-scsi&m=132750980203130
>
> 4) Remaining impediments for merging frontswap
>
> 5) Page flags and 64-bit-only... what are the tradeoffs?

I am interested in these topics.

-- 
All rights reversed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>