Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1370504 > unrolled thread
| Started by | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| First post | 2016-04-04 11:40 +0200 |
| Last post | 2016-04-04 13:10 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2 4/4] mm, compaction: direct freepage allocation for async direct compaction Mel Gorman <mgorman@techsingularity.net> - 2016-04-04 11:40 +0200
Re: [PATCH v2 4/4] mm, compaction: direct freepage allocation for async direct compaction Vlastimil Babka <vbabka@suse.cz> - 2016-04-04 13:10 +0200
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Date | 2016-04-04 11:40 +0200 |
| Subject | Re: [PATCH v2 4/4] mm, compaction: direct freepage allocation for async direct compaction |
| Message-ID | <rk99g-118-15@gated-at.bofh.it> |
On Thu, Mar 31, 2016 at 10:50:36AM +0200, Vlastimil Babka wrote: > The goal of direct compaction is to quickly make a high-order page available > for the pending allocation. The free page scanner can add significant latency > when searching for migration targets, although to succeed the compaction, the > only important limit on the target free pages is that they must not come from > the same order-aligned block as the migrated pages. > What prevents the free pages being allocated from behind the migration scanner? Having compaction abort when the scanners meet misses compaction opportunities but it avoids the problem of Compactor A using pageblock X as a migration target and Compactor B using pageblock X as a migration source. -- Mel Gorman SUSE Labs
[toc] | [next] | [standalone]
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Date | 2016-04-04 13:10 +0200 |
| Message-ID | <rkaym-289-13@gated-at.bofh.it> |
| In reply to | #1370504 |
On 04/04/2016 11:31 AM, Mel Gorman wrote: > On Thu, Mar 31, 2016 at 10:50:36AM +0200, Vlastimil Babka wrote: >> The goal of direct compaction is to quickly make a high-order page available >> for the pending allocation. The free page scanner can add significant latency >> when searching for migration targets, although to succeed the compaction, the >> only important limit on the target free pages is that they must not come from >> the same order-aligned block as the migrated pages. >> > > What prevents the free pages being allocated from behind the migration > scanner? Having compaction abort when the scanners meet misses > compaction opportunities but it avoids the problem of Compactor A using > pageblock X as a migration target and Compactor B using pageblock X as a > migration source. It's true that there's no complete protection, but parallel async compactions should eventually get detect contention and back off. Sync compaction keeps using the free scanner, so this seemed like a safe thing to attempt in the initial async compaction, without compromising success rates thanks to the followup sync compaction.
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web