Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1165623
| From | Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC PATCH 10/12] mm: add the buddy system interface |
| Date | 2015-06-16 02:40 +0200 |
| Message-ID | <pBN4Z-2YA-3@gated-at.bofh.it> (permalink) |
| References | (3 earlier) <pzoNs-3xC-25@gated-at.bofh.it> <pzEyR-1FE-5@gated-at.bofh.it> <pzV6K-Gk-81@gated-at.bofh.it> <pByfE-6GG-11@gated-at.bofh.it> <pBGmT-1Fl-35@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 2015/06/16 2:20, Luck, Tony wrote: > On Mon, Jun 15, 2015 at 05:47:27PM +0900, Kamezawa Hiroyuki wrote: >> So, there are 3 ideas. >> >> (1) kernel only from MIRROR / user only from MOVABLE (Tony) >> (2) kernel only from MIRROR / user from MOVABLE + MIRROR(ASAP) (AKPM suggested) >> This makes use of the fact MOVABLE memory is reclaimable but Tony pointed out >> the memory reclaim can be critical for GFP_ATOMIC. >> (3) kernel only from MIRROR / user from MOVABLE, special user from MIRROR (Xishi) >> >> 2 Implementation ideas. >> - creating ZONE >> - creating new alloation attribute >> >> I don't convince whether we need some new structure in mm. Isn't it good to use >> ZONE_MOVABLE for not-mirrored memory ? >> Then, disable fallback from ZONE_MOVABLE -> ZONE_NORMAL for (1) and (3) > > We might need to rename it ... right now the memory hotplug > people use ZONE_MOVABLE to indicate regions of physical memory > that can be removed from the system. I'm wondering whether > people will want systems that have both removable and mirrored > areas? Then we have four attribute combinations: > > mirror=no removable=no - prefer to use for user, could use for kernel if we run out of mirror > mirror=no removable=yes - can only be used for user (kernel allocation makes it not-removable) > mirror=yes removable=no - use for kernel, possibly for special users if we define some interface > mirror=yes removable=yes - must not use for kernel ... would have to give to user ... seems like a bad idea to configure a system this way > Thank you for clarification. I see "mirror=no, removable=no" case may require a new name. IMHO, the value of Address-Based-Memory-Mirror is that users can protect their system's important functions without using full-memory mirror. So, I feel thinking "mirror=no, removable=no" just makes our discussion/implemenation complex without real user value. Shouldn't we start with just thiking 2 cases of mirror=no removable=yes mirror=yes removable=no ? And then, if the naming is problem, alias name can be added. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
Re: [RFC PATCH 10/12] mm: add the buddy system interface Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2015-06-09 09:20 +0200
Re: [RFC PATCH 10/12] mm: add the buddy system interface Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2015-06-10 05:10 +0200
Re: [RFC PATCH 10/12] mm: add the buddy system interface Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> - 2015-06-16 02:40 +0200
csiph-web