Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1626048
| From | Vlastimil Babka <vbabka@suse.cz> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/3] mm: consider zone which is not fully populated to have holes |
| Date | 2017-04-19 14:00 +0200 |
| Message-ID | <txWr8-30n-17@gated-at.bofh.it> (permalink) |
| References | <tuFmO-8iD-7@gated-at.bofh.it> <twuQh-6q5-3@gated-at.bofh.it> <twuQi-6q5-11@gated-at.bofh.it> <txwZH-3ZQ-19@gated-at.bofh.it> <txxCq-4sb-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 04/18/2017 11:27 AM, Michal Hocko wrote: > On Tue 18-04-17 10:45:23, Vlastimil Babka wrote: >> On 04/15/2017 02:17 PM, Michal Hocko wrote: >>> From: Michal Hocko <mhocko@suse.com> >>> >> >> My issue with this is that PageReserved can be also set for other >> reasons than offlined block, e.g. by a random driver. So there are two >> suboptimal scenarios: >> >> - PageReserved is set on some page in the middle of pageblock. It won't >> be detected by this patch. This violates the "it would be safer" argument. >> - PageReserved is set on just the first (few) page(s) and because of >> this patch, we skip it completely and won't compact the rest of it. > > Why would that be a big problem? PageReserved is used only very seldom > and few page blocks skipped would seem like a minor issue to me. Yes it's not critical, just suboptimal. Can be improved later. >> So if we decide we really need to check PageReserved to ensure safety, >> then we have to check it on each page. But I hope the existing criteria >> in compaction scanners are sufficient. Unless the semantic is that if >> somebody sets PageReserved, he's free to repurpose the rest of flags at >> his will (IMHO that's not the case). > > I am not aware of any such user. PageReserved has always been about "the > core mm should touch these pages and modify their state" AFAIR. > But I believe that touching those holes just asks for problems so I > would rather have them covered. OK. I guess it's OK to use PageReserved of first pageblock page to determine if we can trust page_zone(), because the memory offline scenario should have sufficient granularity and not make holes inside pageblock? >> The pageblock-level check them becomes a performance optimization so >> when there's an "offline hole", compaction won't iterate it page by >> page. But the downside is the false positive resulting in skipping whole >> pageblock due to single page. >> I guess it's uncommon for a longlived offline holes to exist, so we >> could simply just drop this? > > This is hard to tell but I can imagine that some memory hotplug > balloning drivers might want to offline hole into existing zones. OK.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 1/3] mm: consider zone which is not fully populated to have holes Michal Hocko <mhocko@kernel.org> - 2017-04-15 14:20 +0200
Re: [PATCH 1/3] mm: consider zone which is not fully populated to have holes Vlastimil Babka <vbabka@suse.cz> - 2017-04-18 10:50 +0200
Re: [PATCH 1/3] mm: consider zone which is not fully populated to have holes Michal Hocko <mhocko@kernel.org> - 2017-04-18 11:30 +0200
Re: [PATCH 1/3] mm: consider zone which is not fully populated to have holes Vlastimil Babka <vbabka@suse.cz> - 2017-04-19 14:00 +0200
Re: [PATCH 1/3] mm: consider zone which is not fully populated to have holes Michal Hocko <mhocko@kernel.org> - 2017-04-19 14:20 +0200
Re: [PATCH 1/3] mm: consider zone which is not fully populated to have holes Vlastimil Babka <vbabka@suse.cz> - 2017-04-19 14:40 +0200
Re: [PATCH 1/3] mm: consider zone which is not fully populated to have holes Michal Hocko <mhocko@kernel.org> - 2017-04-19 15:00 +0200
csiph-web