On Tue, Sep 25, 2012 at 01:03:52PM -0700, Andrew Morton wrote:
> On Tue, 25 Sep 2012 10:12:07 +0100
> Mel Gorman wrote:
>
> > First, we'd introduce a variant of get_pageblock_migratetype() that returns
> > all the bits for the pageblock flags and then helpers to extract either the
> >
On Wed, Sep 26, 2012 at 09:49:30AM +0900, Minchan Kim wrote:
> On Tue, Sep 25, 2012 at 10:12:07AM +0100, Mel Gorman wrote:
> > On Mon, Sep 24, 2012 at 02:26:44PM -0700, Andrew Morton wrote:
> > > On Mon, 24 Sep 2012 10:39:38 +0100
> > > Mel Gorman wrote:
> > >
> > > > On Fri, Sep 21, 2012 at
On Wed, Sep 26, 2012 at 09:49:30AM +0900, Minchan Kim wrote:
On Tue, Sep 25, 2012 at 10:12:07AM +0100, Mel Gorman wrote:
On Mon, Sep 24, 2012 at 02:26:44PM -0700, Andrew Morton wrote:
On Mon, 24 Sep 2012 10:39:38 +0100
Mel Gorman mgor...@suse.de wrote:
On Fri, Sep 21, 2012 at
On Tue, Sep 25, 2012 at 01:03:52PM -0700, Andrew Morton wrote:
On Tue, 25 Sep 2012 10:12:07 +0100
Mel Gorman mgor...@suse.de wrote:
First, we'd introduce a variant of get_pageblock_migratetype() that returns
all the bits for the pageblock flags and then helpers to extract either the
On Tue, Sep 25, 2012 at 10:12:07AM +0100, Mel Gorman wrote:
> On Mon, Sep 24, 2012 at 02:26:44PM -0700, Andrew Morton wrote:
> > On Mon, 24 Sep 2012 10:39:38 +0100
> > Mel Gorman wrote:
> >
> > > On Fri, Sep 21, 2012 at 02:36:56PM -0700, Andrew Morton wrote:
> > >
> > > > Also, what has to be
On Tue, 25 Sep 2012 10:12:07 +0100
Mel Gorman wrote:
> First, we'd introduce a variant of get_pageblock_migratetype() that returns
> all the bits for the pageblock flags and then helpers to extract either the
> migratetype or the PG_migrate_skip. We already are incurring the cost of
>
On Mon, Sep 24, 2012 at 02:26:44PM -0700, Andrew Morton wrote:
> On Mon, 24 Sep 2012 10:39:38 +0100
> Mel Gorman wrote:
>
> > On Fri, Sep 21, 2012 at 02:36:56PM -0700, Andrew Morton wrote:
> >
> > > Also, what has to be done to avoid the polling altogether? eg/ie, zap
> > > a pageblock's
On Mon, Sep 24, 2012 at 02:26:44PM -0700, Andrew Morton wrote:
On Mon, 24 Sep 2012 10:39:38 +0100
Mel Gorman mgor...@suse.de wrote:
On Fri, Sep 21, 2012 at 02:36:56PM -0700, Andrew Morton wrote:
Also, what has to be done to avoid the polling altogether? eg/ie, zap
a pageblock's
On Tue, 25 Sep 2012 10:12:07 +0100
Mel Gorman mgor...@suse.de wrote:
First, we'd introduce a variant of get_pageblock_migratetype() that returns
all the bits for the pageblock flags and then helpers to extract either the
migratetype or the PG_migrate_skip. We already are incurring the cost of
On Tue, Sep 25, 2012 at 10:12:07AM +0100, Mel Gorman wrote:
On Mon, Sep 24, 2012 at 02:26:44PM -0700, Andrew Morton wrote:
On Mon, 24 Sep 2012 10:39:38 +0100
Mel Gorman mgor...@suse.de wrote:
On Fri, Sep 21, 2012 at 02:36:56PM -0700, Andrew Morton wrote:
Also, what has to be
On Mon, 24 Sep 2012 10:39:38 +0100
Mel Gorman wrote:
> On Fri, Sep 21, 2012 at 02:36:56PM -0700, Andrew Morton wrote:
>
> > Also, what has to be done to avoid the polling altogether? eg/ie, zap
> > a pageblock's PB_migrate_skip synchronously, when something was done to
> > that pageblock which
On Fri, Sep 21, 2012 at 02:36:56PM -0700, Andrew Morton wrote:
> On Fri, 21 Sep 2012 11:46:22 +0100
> Mel Gorman wrote:
>
> > When compaction was implemented it was known that scanning could potentially
> > be excessive. The ideal was that a counter be maintained for each pageblock
> > but
On Fri, Sep 21, 2012 at 02:36:56PM -0700, Andrew Morton wrote:
On Fri, 21 Sep 2012 11:46:22 +0100
Mel Gorman mgor...@suse.de wrote:
When compaction was implemented it was known that scanning could potentially
be excessive. The ideal was that a counter be maintained for each pageblock
but
On Mon, 24 Sep 2012 10:39:38 +0100
Mel Gorman mgor...@suse.de wrote:
On Fri, Sep 21, 2012 at 02:36:56PM -0700, Andrew Morton wrote:
Also, what has to be done to avoid the polling altogether? eg/ie, zap
a pageblock's PB_migrate_skip synchronously, when something was done to
that
On Fri, 21 Sep 2012 11:46:22 +0100
Mel Gorman wrote:
> When compaction was implemented it was known that scanning could potentially
> be excessive. The ideal was that a counter be maintained for each pageblock
> but maintaining this information would incur a severe penalty due to a
> shared
On Fri, Sep 21, 2012 at 11:46:22AM +0100, Mel Gorman wrote:
> When compaction was implemented it was known that scanning could potentially
> be excessive. The ideal was that a counter be maintained for each pageblock
> but maintaining this information would incur a severe penalty due to a
> shared
When compaction was implemented it was known that scanning could potentially
be excessive. The ideal was that a counter be maintained for each pageblock
but maintaining this information would incur a severe penalty due to a
shared writable cache line. It has reached the point where the scanning
When compaction was implemented it was known that scanning could potentially
be excessive. The ideal was that a counter be maintained for each pageblock
but maintaining this information would incur a severe penalty due to a
shared writable cache line. It has reached the point where the scanning
On Fri, Sep 21, 2012 at 11:46:22AM +0100, Mel Gorman wrote:
When compaction was implemented it was known that scanning could potentially
be excessive. The ideal was that a counter be maintained for each pageblock
but maintaining this information would incur a severe penalty due to a
shared
On Fri, 21 Sep 2012 11:46:22 +0100
Mel Gorman mgor...@suse.de wrote:
When compaction was implemented it was known that scanning could potentially
be excessive. The ideal was that a counter be maintained for each pageblock
but maintaining this information would incur a severe penalty due to a
20 matches
Mail list logo
