Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Wed, 2 Feb 2005, Andrew Morton wrote: > Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > > > > What are your thoughts about inclusion of Mel's allocator work on -mm ? > > It's sitting in my to-do pile. Tell me when you need my prezeroing patches on top of mel's patches - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
Hi Andrew, What are your thoughts about inclusion of Mel's allocator work on -mm ? On Wed, Feb 02, 2005 at 12:31:36AM +, Mel Gorman wrote: > On Tue, 1 Feb 2005, Christoph Lameter wrote: > > > On Tue, 1 Feb 2005, Mel Gorman wrote: > > > > > > Would it not be better to zero the global 2^MAX_ORDER pages by the scrub > > > > daemon and have a global zeroed page list? That way you may avoid > > > > zeroing > > > > when splitting pages? > > > > > > > > > > Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon > > > is going to be doing nothing which is why I think it needs to look at the > > > free pages of lower orders. > > > > > > That is solveable though in one of two ways. One, the scrub daemon can > > > zero pages from the global list and then add them to the USERZERO pool. It > > > has the advantage of requiring no more memory and is simple. The second is > > > to create a second global list. However, I think it only makes sense to > > > have this as part of the scrub daemon patch (I can write it if thats a > > > problem) rather than a standalone patch from me. > > > > Approach one is fine and I will do an update the remaining prezero patches > > to do just that. > > There is another problem with approach one. Assuming all 2^MAX_ORDER pages > have been zeroed and in USERZERO pool and there are no other free pages, > an allocation for the USERRCLM pool would search all the other pools > before finding the zerod pages. This could really slow things up but it is > not a problem approach two suffers from. > > > When will your patches be in Linus tree? ;-) > > > > Your guess is as good as mine :) . I am fairly sure the allocator is > somewhere in Andrew's list of patches to look at to consider for inclusion > into -mm so I suppose it'll get a spin in that tree when he feels it's > ready. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
Marcelo Tosatti <[EMAIL PROTECTED]> wrote: > > What are your thoughts about inclusion of Mel's allocator work on -mm ? It's sitting in my to-do pile. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
Marcelo Tosatti [EMAIL PROTECTED] wrote: What are your thoughts about inclusion of Mel's allocator work on -mm ? It's sitting in my to-do pile. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
Hi Andrew, What are your thoughts about inclusion of Mel's allocator work on -mm ? On Wed, Feb 02, 2005 at 12:31:36AM +, Mel Gorman wrote: On Tue, 1 Feb 2005, Christoph Lameter wrote: On Tue, 1 Feb 2005, Mel Gorman wrote: Would it not be better to zero the global 2^MAX_ORDER pages by the scrub daemon and have a global zeroed page list? That way you may avoid zeroing when splitting pages? Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon is going to be doing nothing which is why I think it needs to look at the free pages of lower orders. That is solveable though in one of two ways. One, the scrub daemon can zero pages from the global list and then add them to the USERZERO pool. It has the advantage of requiring no more memory and is simple. The second is to create a second global list. However, I think it only makes sense to have this as part of the scrub daemon patch (I can write it if thats a problem) rather than a standalone patch from me. Approach one is fine and I will do an update the remaining prezero patches to do just that. There is another problem with approach one. Assuming all 2^MAX_ORDER pages have been zeroed and in USERZERO pool and there are no other free pages, an allocation for the USERRCLM pool would search all the other pools before finding the zerod pages. This could really slow things up but it is not a problem approach two suffers from. When will your patches be in Linus tree? ;-) Your guess is as good as mine :) . I am fairly sure the allocator is somewhere in Andrew's list of patches to look at to consider for inclusion into -mm so I suppose it'll get a spin in that tree when he feels it's ready. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Wed, 2 Feb 2005, Andrew Morton wrote: Marcelo Tosatti [EMAIL PROTECTED] wrote: What are your thoughts about inclusion of Mel's allocator work on -mm ? It's sitting in my to-do pile. Tell me when you need my prezeroing patches on top of mel's patches - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Tue, 1 Feb 2005, Christoph Lameter wrote: > On Tue, 1 Feb 2005, Mel Gorman wrote: > > > > Would it not be better to zero the global 2^MAX_ORDER pages by the scrub > > > daemon and have a global zeroed page list? That way you may avoid zeroing > > > when splitting pages? > > > > > > > Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon > > is going to be doing nothing which is why I think it needs to look at the > > free pages of lower orders. > > > > That is solveable though in one of two ways. One, the scrub daemon can > > zero pages from the global list and then add them to the USERZERO pool. It > > has the advantage of requiring no more memory and is simple. The second is > > to create a second global list. However, I think it only makes sense to > > have this as part of the scrub daemon patch (I can write it if thats a > > problem) rather than a standalone patch from me. > > Approach one is fine and I will do an update the remaining prezero patches > to do just that. There is another problem with approach one. Assuming all 2^MAX_ORDER pages have been zeroed and in USERZERO pool and there are no other free pages, an allocation for the USERRCLM pool would search all the other pools before finding the zerod pages. This could really slow things up but it is not a problem approach two suffers from. > When will your patches be in Linus tree? ;-) > Your guess is as good as mine :) . I am fairly sure the allocator is somewhere in Andrew's list of patches to look at to consider for inclusion into -mm so I suppose it'll get a spin in that tree when he feels it's ready. -- Mel Gorman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Tue, 1 Feb 2005, Mel Gorman wrote: > > Would it not be better to zero the global 2^MAX_ORDER pages by the scrub > > daemon and have a global zeroed page list? That way you may avoid zeroing > > when splitting pages? > > > > Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon > is going to be doing nothing which is why I think it needs to look at the > free pages of lower orders. > > That is solveable though in one of two ways. One, the scrub daemon can > zero pages from the global list and then add them to the USERZERO pool. It > has the advantage of requiring no more memory and is simple. The second is > to create a second global list. However, I think it only makes sense to > have this as part of the scrub daemon patch (I can write it if thats a > problem) rather than a standalone patch from me. Approach one is fine and I will do an update the remaining prezero patches to do just that. When will your patches be in Linus tree? ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Tue, 1 Feb 2005, Christoph Lameter wrote: > On Tue, 1 Feb 2005, Mel Gorman wrote: > > > This is a patch that makes a step towards tieing the modified allocator > > for reducing fragmentation with the prezeroing of pages that is based > > on a discussion with Christoph. When a block has to be split to satisfy a > > zero-page, both buddies are zero'd, one is allocated and the other is placed > > on the free-list for the USERZERO pool. Care is taken to make sure the pools > > are not accidently fragmented. > > Thanks for integrating the page zero stuff. If you are zeroing pages > before their are fragmented then we may not need scrubd anymore. On the > other hand, larger than necessary zeroing may be performaned in the hot > code paths which may result in sporadically longer delays during > allocation (well but then the page_allocator can generate these delays for > a number of reasons). > I am not sure it eliminates the need for scrubd just yet. I will only zero out more pages than necessary when a block of pages is being split but once the zeroing has taken place, I will not need to zero again until all the zerod pages are used. So even if the system was doing nothing else, my patch will not bother zeroing out anything. Right now, this patch is expensive because there is no cheap mechanism in place that makes zering large groups of pages worth it (all prep_zero_page() is doing is iterating and zeroing one at a time). For this patch to make the most sense, your mechanism for quickly zeroing large blocks of pages needs to be place. > > I would expect that a scrubber daemon would go through the KERNNORCLM pool, > > remove pages, scrub them and move them to USERZERO. It is important that > > pages > > not be moved from the USERRCLM or KERNRCLM pools as it'll cause > > fragmentation > > problems over time. > > Would it not be better to zero the global 2^MAX_ORDER pages by the scrub > daemon and have a global zeroed page list? That way you may avoid zeroing > when splitting pages? > Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon is going to be doing nothing which is why I think it needs to look at the free pages of lower orders. That is solveable though in one of two ways. One, the scrub daemon can zero pages from the global list and then add them to the USERZERO pool. It has the advantage of requiring no more memory and is simple. The second is to create a second global list. However, I think it only makes sense to have this as part of the scrub daemon patch (I can write it if thats a problem) rather than a standalone patch from me. -- Mel Gorman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Tue, 1 Feb 2005, Mel Gorman wrote: > This is a patch that makes a step towards tieing the modified allocator > for reducing fragmentation with the prezeroing of pages that is based > on a discussion with Christoph. When a block has to be split to satisfy a > zero-page, both buddies are zero'd, one is allocated and the other is placed > on the free-list for the USERZERO pool. Care is taken to make sure the pools > are not accidently fragmented. Thanks for integrating the page zero stuff. If you are zeroing pages before their are fragmented then we may not need scrubd anymore. On the other hand, larger than necessary zeroing may be performaned in the hot code paths which may result in sporadically longer delays during allocation (well but then the page_allocator can generate these delays for a number of reasons). > I would expect that a scrubber daemon would go through the KERNNORCLM pool, > remove pages, scrub them and move them to USERZERO. It is important that pages > not be moved from the USERRCLM or KERNRCLM pools as it'll cause fragmentation > problems over time. Would it not be better to zero the global 2^MAX_ORDER pages by the scrub daemon and have a global zeroed page list? That way you may avoid zeroing when splitting pages? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Tue, 1 Feb 2005, Mel Gorman wrote: This is a patch that makes a step towards tieing the modified allocator for reducing fragmentation with the prezeroing of pages that is based on a discussion with Christoph. When a block has to be split to satisfy a zero-page, both buddies are zero'd, one is allocated and the other is placed on the free-list for the USERZERO pool. Care is taken to make sure the pools are not accidently fragmented. Thanks for integrating the page zero stuff. If you are zeroing pages before their are fragmented then we may not need scrubd anymore. On the other hand, larger than necessary zeroing may be performaned in the hot code paths which may result in sporadically longer delays during allocation (well but then the page_allocator can generate these delays for a number of reasons). I would expect that a scrubber daemon would go through the KERNNORCLM pool, remove pages, scrub them and move them to USERZERO. It is important that pages not be moved from the USERRCLM or KERNRCLM pools as it'll cause fragmentation problems over time. Would it not be better to zero the global 2^MAX_ORDER pages by the scrub daemon and have a global zeroed page list? That way you may avoid zeroing when splitting pages? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Tue, 1 Feb 2005, Christoph Lameter wrote: On Tue, 1 Feb 2005, Mel Gorman wrote: This is a patch that makes a step towards tieing the modified allocator for reducing fragmentation with the prezeroing of pages that is based on a discussion with Christoph. When a block has to be split to satisfy a zero-page, both buddies are zero'd, one is allocated and the other is placed on the free-list for the USERZERO pool. Care is taken to make sure the pools are not accidently fragmented. Thanks for integrating the page zero stuff. If you are zeroing pages before their are fragmented then we may not need scrubd anymore. On the other hand, larger than necessary zeroing may be performaned in the hot code paths which may result in sporadically longer delays during allocation (well but then the page_allocator can generate these delays for a number of reasons). I am not sure it eliminates the need for scrubd just yet. I will only zero out more pages than necessary when a block of pages is being split but once the zeroing has taken place, I will not need to zero again until all the zerod pages are used. So even if the system was doing nothing else, my patch will not bother zeroing out anything. Right now, this patch is expensive because there is no cheap mechanism in place that makes zering large groups of pages worth it (all prep_zero_page() is doing is iterating and zeroing one at a time). For this patch to make the most sense, your mechanism for quickly zeroing large blocks of pages needs to be place. I would expect that a scrubber daemon would go through the KERNNORCLM pool, remove pages, scrub them and move them to USERZERO. It is important that pages not be moved from the USERRCLM or KERNRCLM pools as it'll cause fragmentation problems over time. Would it not be better to zero the global 2^MAX_ORDER pages by the scrub daemon and have a global zeroed page list? That way you may avoid zeroing when splitting pages? Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon is going to be doing nothing which is why I think it needs to look at the free pages of lower orders. That is solveable though in one of two ways. One, the scrub daemon can zero pages from the global list and then add them to the USERZERO pool. It has the advantage of requiring no more memory and is simple. The second is to create a second global list. However, I think it only makes sense to have this as part of the scrub daemon patch (I can write it if thats a problem) rather than a standalone patch from me. -- Mel Gorman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Tue, 1 Feb 2005, Mel Gorman wrote: Would it not be better to zero the global 2^MAX_ORDER pages by the scrub daemon and have a global zeroed page list? That way you may avoid zeroing when splitting pages? Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon is going to be doing nothing which is why I think it needs to look at the free pages of lower orders. That is solveable though in one of two ways. One, the scrub daemon can zero pages from the global list and then add them to the USERZERO pool. It has the advantage of requiring no more memory and is simple. The second is to create a second global list. However, I think it only makes sense to have this as part of the scrub daemon patch (I can write it if thats a problem) rather than a standalone patch from me. Approach one is fine and I will do an update the remaining prezero patches to do just that. When will your patches be in Linus tree? ;-) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Helping prezoring with reduced fragmentation allocation
On Tue, 1 Feb 2005, Christoph Lameter wrote: On Tue, 1 Feb 2005, Mel Gorman wrote: Would it not be better to zero the global 2^MAX_ORDER pages by the scrub daemon and have a global zeroed page list? That way you may avoid zeroing when splitting pages? Maybe, but right now when there are no 2^MAX_ORDER pages, the scrub daemon is going to be doing nothing which is why I think it needs to look at the free pages of lower orders. That is solveable though in one of two ways. One, the scrub daemon can zero pages from the global list and then add them to the USERZERO pool. It has the advantage of requiring no more memory and is simple. The second is to create a second global list. However, I think it only makes sense to have this as part of the scrub daemon patch (I can write it if thats a problem) rather than a standalone patch from me. Approach one is fine and I will do an update the remaining prezero patches to do just that. There is another problem with approach one. Assuming all 2^MAX_ORDER pages have been zeroed and in USERZERO pool and there are no other free pages, an allocation for the USERRCLM pool would search all the other pools before finding the zerod pages. This could really slow things up but it is not a problem approach two suffers from. When will your patches be in Linus tree? ;-) Your guess is as good as mine :) . I am fairly sure the allocator is somewhere in Andrew's list of patches to look at to consider for inclusion into -mm so I suppose it'll get a spin in that tree when he feels it's ready. -- Mel Gorman - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
