Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1739778
| From | Mel Gorman <mgorman@techsingularity.net> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC 0/2] Use HighAtomic against long-term fragmentation |
| Date | 2017-09-26 12:50 +0200 |
| Message-ID | <utVB8-3Ca-15@gated-at.bofh.it> (permalink) |
| References | <utU2m-2KN-23@gated-at.bofh.it> <utUOK-33E-21@gated-at.bofh.it> <utUYq-3mq-11@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Tue, Sep 26, 2017 at 06:04:04PM +0800, Hui Zhu wrote: > 2017-09-26 17:51 GMT+08:00 Mel Gorman <mgorman@techsingularity.net>: > > On Tue, Sep 26, 2017 at 04:46:42PM +0800, Hui Zhu wrote: > >> Current HighAtomic just to handle the high atomic page alloc. > >> But I found that use it handle the normal unmovable continuous page > >> alloc will help to against long-term fragmentation. > >> > > > > This is not wise. High-order atomic allocations do not always have a > > smooth recovery path such as network drivers with large MTUs that have no > > choice but to drop the traffic and hope for a retransmit. That's why they > > have the highatomic reserve. If the reserve is used for normal unmovable > > allocations then allocation requests that could have waited for reclaim > > may cause high-order atomic allocations to fail. Changing it may allow > > improve latencies in some limited cases while causing functional failures > > in others. If there is a special case where there are a large number of > > other high-order allocations then I would suggest increasing min_free_kbytes > > instead as a workaround. > > I think let 0 order unmovable page alloc and other order unmovable pages > alloc use different migrate types will help against long-term > fragmentation. > That can already happen through the migratetype fallback lists. > Do you think kernel can add a special migrate type for big than 0 order > unmovable pages alloc? > Technically, yes but the barrier to entry will be high as you'll have to explain carefully why it is necessary including information on why order-0 pages cannot be used, back it up with data showing what is improved as a result and justify why potentially forcing normal workloads to reclaim due to being unable to use the high-order reserve is ok. If it's a limitation of a specific driver then it'll be asked why that driver does not have a dedicated pool (which is functionally similar to having a dedicated reserve). -- Mel Gorman SUSE Labs
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[RFC 0/2] Use HighAtomic against long-term fragmentation Hui Zhu <zhuhui@xiaomi.com> - 2017-09-26 11:10 +0200
[RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0 Hui Zhu <zhuhui@xiaomi.com> - 2017-09-26 11:10 +0200
Re: [RFC 1/2] Try to use HighAtomic if try to alloc umovable page that order is not 0 Michal Hocko <mhocko@kernel.org> - 2017-09-26 12:50 +0200
Re: [RFC 0/2] Use HighAtomic against long-term fragmentation Mel Gorman <mgorman@techsingularity.net> - 2017-09-26 12:00 +0200
Re: [RFC 0/2] Use HighAtomic against long-term fragmentation Hui Zhu <teawater@gmail.com> - 2017-09-26 12:10 +0200
Re: [RFC 0/2] Use HighAtomic against long-term fragmentation Mel Gorman <mgorman@techsingularity.net> - 2017-09-26 12:50 +0200
csiph-web