Hi Mel,
On Fri, Aug 10, 2012 at 09:34:38AM +0100, Mel Gorman wrote:
> On Fri, Aug 10, 2012 at 08:27:33AM +0900, Minchan Kim wrote:
> > >
> > >
> > > The intention is that an allocation can fail but each subsequent attempt
> > > will
> > > try harder until there is success. Each allocation
On Fri, Aug 10, 2012 at 08:27:33AM +0900, Minchan Kim wrote:
> >
> >
> > The intention is that an allocation can fail but each subsequent attempt
> > will
> > try harder until there is success. Each allocation request does a portion
> > of the necessary work to spread the cost between multiple
On Thu, Aug 09, 2012 at 04:29:57PM -0400, Rik van Riel wrote:
> On 08/09/2012 05:20 AM, Mel Gorman wrote:
>
> >The intention is that an allocation can fail but each subsequent attempt will
> >try harder until there is success. Each allocation request does a portion
> >of the necessary work to
On Thu, Aug 09, 2012 at 04:29:57PM -0400, Rik van Riel wrote:
On 08/09/2012 05:20 AM, Mel Gorman wrote:
The intention is that an allocation can fail but each subsequent attempt will
try harder until there is success. Each allocation request does a portion
of the necessary work to spread the
On Fri, Aug 10, 2012 at 08:27:33AM +0900, Minchan Kim wrote:
SNIP
The intention is that an allocation can fail but each subsequent attempt
will
try harder until there is success. Each allocation request does a portion
of the necessary work to spread the cost between multiple requests.
Hi Mel,
On Fri, Aug 10, 2012 at 09:34:38AM +0100, Mel Gorman wrote:
On Fri, Aug 10, 2012 at 08:27:33AM +0900, Minchan Kim wrote:
SNIP
The intention is that an allocation can fail but each subsequent attempt
will
try harder until there is success. Each allocation request does a
On Thu, Aug 09, 2012 at 10:20:35AM +0100, Mel Gorman wrote:
> On Thu, Aug 09, 2012 at 05:27:15PM +0900, Minchan Kim wrote:
> > > > > + * pages reclaimed based on the number of consecutive allocation
> > > > > + * failures
> > > > > + */
> > > > > + zone = lruvec_zone(lruvec);
>
On 08/09/2012 05:20 AM, Mel Gorman wrote:
The intention is that an allocation can fail but each subsequent attempt will
try harder until there is success. Each allocation request does a portion
of the necessary work to spread the cost between multiple requests.
At some point we need to stop
On Thu, Aug 09, 2012 at 05:27:15PM +0900, Minchan Kim wrote:
> > > > + * pages reclaimed based on the number of consecutive allocation
> > > > + * failures
> > > > + */
> > > > + zone = lruvec_zone(lruvec);
> > > > + if (zone->compact_order_failed >= sc->order)
> > >
> > >
On Thu, Aug 09, 2012 at 08:49:50AM +0100, Mel Gorman wrote:
> On Thu, Aug 09, 2012 at 08:51:27AM +0900, Minchan Kim wrote:
> > > > > > Just out of curiosity.
> > > > > > What's the problem did you see? (ie, What's the problem do this
> > > > > > patch solve?)
> > > > >
> > > > > Everythign in
On Thu, Aug 09, 2012 at 08:51:27AM +0900, Minchan Kim wrote:
> > > > > Just out of curiosity.
> > > > > What's the problem did you see? (ie, What's the problem do this patch
> > > > > solve?)
> > > >
> > > > Everythign in this series is related to the problem in the leader - high
> > > > order
On Thu, Aug 09, 2012 at 08:51:27AM +0900, Minchan Kim wrote:
Just out of curiosity.
What's the problem did you see? (ie, What's the problem do this patch
solve?)
Everythign in this series is related to the problem in the leader - high
order allocation success rates are
On Thu, Aug 09, 2012 at 08:49:50AM +0100, Mel Gorman wrote:
On Thu, Aug 09, 2012 at 08:51:27AM +0900, Minchan Kim wrote:
Just out of curiosity.
What's the problem did you see? (ie, What's the problem do this
patch solve?)
Everythign in this series is related to the
On Thu, Aug 09, 2012 at 05:27:15PM +0900, Minchan Kim wrote:
+ * pages reclaimed based on the number of consecutive allocation
+ * failures
+ */
+ zone = lruvec_zone(lruvec);
+ if (zone-compact_order_failed = sc-order)
I can't understand this part.
On 08/09/2012 05:20 AM, Mel Gorman wrote:
The intention is that an allocation can fail but each subsequent attempt will
try harder until there is success. Each allocation request does a portion
of the necessary work to spread the cost between multiple requests.
At some point we need to stop
On Thu, Aug 09, 2012 at 10:20:35AM +0100, Mel Gorman wrote:
On Thu, Aug 09, 2012 at 05:27:15PM +0900, Minchan Kim wrote:
+ * pages reclaimed based on the number of consecutive allocation
+ * failures
+ */
+ zone = lruvec_zone(lruvec);
+ if
On Wed, Aug 08, 2012 at 09:51:12AM +0100, Mel Gorman wrote:
> On Wed, Aug 08, 2012 at 05:27:38PM +0900, Minchan Kim wrote:
> > On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote:
> > > On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
> > > > Hi Mel,
> > > >
> > > > Just out of
On Wed, Aug 08, 2012 at 05:27:38PM +0900, Minchan Kim wrote:
> On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote:
> > On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
> > > Hi Mel,
> > >
> > > Just out of curiosity.
> > > What's the problem did you see? (ie, What's the
On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote:
> On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
> > Hi Mel,
> >
> > Just out of curiosity.
> > What's the problem did you see? (ie, What's the problem do this patch
> > solve?)
>
> Everythign in this series is related to
On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
> Hi Mel,
>
> Just out of curiosity.
> What's the problem did you see? (ie, What's the problem do this patch solve?)
Everythign in this series is related to the problem in the leader - high
order allocation success rates are lower.
On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
Hi Mel,
Just out of curiosity.
What's the problem did you see? (ie, What's the problem do this patch solve?)
Everythign in this series is related to the problem in the leader - high
order allocation success rates are lower. This
On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote:
On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
Hi Mel,
Just out of curiosity.
What's the problem did you see? (ie, What's the problem do this patch
solve?)
Everythign in this series is related to the problem
On Wed, Aug 08, 2012 at 05:27:38PM +0900, Minchan Kim wrote:
On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote:
On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
Hi Mel,
Just out of curiosity.
What's the problem did you see? (ie, What's the problem do this patch
On Wed, Aug 08, 2012 at 09:51:12AM +0100, Mel Gorman wrote:
On Wed, Aug 08, 2012 at 05:27:38PM +0900, Minchan Kim wrote:
On Wed, Aug 08, 2012 at 08:55:26AM +0100, Mel Gorman wrote:
On Wed, Aug 08, 2012 at 10:48:24AM +0900, Minchan Kim wrote:
Hi Mel,
Just out of curiosity.
Hi Mel,
Just out of curiosity.
What's the problem did you see? (ie, What's the problem do this patch solve?)
AFAIUC, it seem to solve consecutive allocation success ratio through
getting several free pageblocks all at once in a process/kswapd
reclaim context. Right?
On Tue, Aug 07, 2012 at
On 08/07/2012 08:31 AM, Mel Gorman wrote:
If allocation fails after compaction then compaction may be deferred for
a number of allocation attempts. If there are subsequent failures,
compact_defer_shift is increased to defer for longer periods. This patch
uses that information to scale the number
If allocation fails after compaction then compaction may be deferred for
a number of allocation attempts. If there are subsequent failures,
compact_defer_shift is increased to defer for longer periods. This patch
uses that information to scale the number of pages reclaimed with
compact_defer_shift
If allocation fails after compaction then compaction may be deferred for
a number of allocation attempts. If there are subsequent failures,
compact_defer_shift is increased to defer for longer periods. This patch
uses that information to scale the number of pages reclaimed with
compact_defer_shift
On 08/07/2012 08:31 AM, Mel Gorman wrote:
If allocation fails after compaction then compaction may be deferred for
a number of allocation attempts. If there are subsequent failures,
compact_defer_shift is increased to defer for longer periods. This patch
uses that information to scale the number
Hi Mel,
Just out of curiosity.
What's the problem did you see? (ie, What's the problem do this patch solve?)
AFAIUC, it seem to solve consecutive allocation success ratio through
getting several free pageblocks all at once in a process/kswapd
reclaim context. Right?
On Tue, Aug 07, 2012 at
30 matches
Mail list logo
