search for: pageblock

...39;NMI_SHIFT'? #define HPAGE_SHIFT PMD_SHIFT ^ arch/riscv/include/asm/page.h:27:34: note: in expansion of macro 'HPAGE_SHIFT' #define HUGETLB_PAGE_ORDER (HPAGE_SHIFT - PAGE_SHIFT) ^~~~~~~~~~~ include/linux/pageblock-flags.h:41:26: note: in expansion of macro 'HUGETLB_PAGE_ORDER' #define pageblock_order HUGETLB_PAGE_ORDER ^~~~~~~~~~~~~~~~~~ >> include/linux/page_reporting.h:9:34: note: in expansion of macro 'pageblock_order' #define PAGE_REPORTING_MIN_...

...avid Hildenbrand <david at redhat.com> > > Hi David, > > That 'return -EAGAIN' was added as a sort of synchronization mechanism. > See commit message for 2c7452a075d4d. Before adding the 'return -EAGAIN', > I could create races which would abandon isolated pageblocks. Repeating > those races over and over would result in a good chunk of system memory > being isolated and unusable. It's actually -EBUSY, it should maybe later be changed to -EAGAIN (see comment), so caller can decide to retry immediately. Other discussion. > > Admittedly, thes...

...oviding better documentation of how ZONE_MOVABLE interacts with different kind of unmovable pages (memory offlining vs. alloc_contig_range()). v4 -> v5: - Rename "mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()" to "mm/page_isolation: exit early when pageblock is isolated in set_migratetype_isolate()" as I was messing up things while reshuffling patches (dump_page(NULL) could never happen, only the WARN_ON_ONCE()) -- Clarify in the description that this is currently a cleanup only - "mm: document semantics of ZONE_MOVABLE" -- Clarified...

...oviding better documentation of how ZONE_MOVABLE interacts with different kind of unmovable pages (memory offlining vs. alloc_contig_range()). v4 -> v5: - Rename "mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()" to "mm/page_isolation: exit early when pageblock is isolated in set_migratetype_isolate()" as I was messing up things while reshuffling patches (dump_page(NULL) could never happen, only the WARN_ON_ONCE()) -- Clarify in the description that this is currently a cleanup only - "mm: document semantics of ZONE_MOVABLE" -- Clarified...

Currently, virtio-mem does not really support ZONE_MOVABLE. While it allows to online fully plugged memory blocks to ZONE_MOVABLE, it does not allow to online partially-plugged memory blocks to ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising for users (especially, if onlining suddenly fails). Let's support partially plugged memory

Currently, virtio-mem does not really support ZONE_MOVABLE. While it allows to online fully plugged memory blocks to ZONE_MOVABLE, it does not allow to online partially-plugged memory blocks to ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising for users (especially, if onlining suddenly fails). Let's support partially plugged memory

...wrote: > Recently, I got many reports about perfermance degradation in embedded > system(Android mobile phone, webOS TV and so on) and easy fork fail. > > The problem was fragmentation caused by zram and GPU driver mainly. > With memory pressure, their pages were spread out all of pageblock and > it cannot be migrated with current compaction algorithm which supports > only LRU pages. In the end, compaction cannot work well so reclaimer > shrinks all of working set pages. It made system very slow and even to > fail to fork easily which requires order-[2 or 3] allocations. &...

...wrote: > Recently, I got many reports about perfermance degradation in embedded > system(Android mobile phone, webOS TV and so on) and easy fork fail. > > The problem was fragmentation caused by zram and GPU driver mainly. > With memory pressure, their pages were spread out all of pageblock and > it cannot be migrated with current compaction algorithm which supports > only LRU pages. In the end, compaction cannot work well so reclaimer > shrinks all of working set pages. It made system very slow and even to > fail to fork easily which requires order-[2 or 3] allocations. &...

...n 06/30/20 at 04:26pm, David Hildenbrand wrote: >> Inside has_unmovable_pages(), we have a comment describing how unmovable >> data could end up in ZONE_MOVABLE - via "movable_core". Also, besides > ~~~ 'movablecore' >> checking if the first page in the pageblock is reserved, we don't >> perform any further checks in case of ZONE_MOVABLE. >> >> In case of memory offlining, we set REPORT_FAILURE, properly >> dump_page() the page and handle the error gracefully. >> alloc_contig_pages() users currently never allocate from ZONE...

> Am 29.07.2020 um 20:36 schrieb Mike Kravetz <mike.kravetz at oracle.com>: > > ?On 7/29/20 11:08 AM, David Hildenbrand wrote: >> I have no clue what you mean with "reintroducing this abandoning of >> pageblocks". All this patch is changing is not doing the dump_page() - >> or am I missing something important? > > My apologies!!! > No worries, thanks for reviewing!! > I got confused when I saw 'Return -EBUSY' removed from the comment and > assumed the code would not r...

I sent a patch about page allocation for less fragmentation. http://permalink.gmane.org/gmane.linux.kernel.mm/130599 It proposes a page allocator allocates pages in the same pageblock for the drivers to move their unmovable pages. Some drivers which comsumes many pages and increases system fragmentation use the allocator to move their pages to decrease fragmentation. I think I can try another approach. There is a compaction code for balloon pages. But the compaction code cannot...

I sent a patch about page allocation for less fragmentation. http://permalink.gmane.org/gmane.linux.kernel.mm/130599 It proposes a page allocator allocates pages in the same pageblock for the drivers to move their unmovable pages. Some drivers which comsumes many pages and increases system fragmentation use the allocator to move their pages to decrease fragmentation. I think I can try another approach. There is a compaction code for balloon pages. But the compaction code cannot...

...ch feature for zsmalloc. Thanks for the work. On Wed, Apr 01, 2015 at 08:11:30AM +0900, Gioh Kim wrote: > I sent a patch about page allocation for less fragmentation. > http://permalink.gmane.org/gmane.linux.kernel.mm/130599 > > It proposes a page allocator allocates pages in the same pageblock > for the drivers to move their unmovable pages. Some drivers which comsumes many pages > and increases system fragmentation use the allocator to move their pages to > decrease fragmentation. > > I think I can try another approach. > There is a compaction code for balloon pages....

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot work well so reclaimer shrinks all of working set pages. It made system very slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot work well so reclaimer shrinks all of working set pages. It made system very slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot work well so reclaimer shrinks all of working set pages. It made system very slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is...

Recently, I got many reports about perfermance degradation in embedded system(Android mobile phone, webOS TV and so on) and easy fork fail. The problem was fragmentation caused by zram and GPU driver mainly. With memory pressure, their pages were spread out all of pageblock and it cannot be migrated with current compaction algorithm which supports only LRU pages. In the end, compaction cannot work well so reclaimer shrinks all of working set pages. It made system very slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is...

@Andrew, @Mst, I suggest the whole series (including the virtio-mem change) goes via the -mm tree. Currently, virtio-mem does not really support ZONE_MOVABLE. While it allows to online fully plugged memory blocks to ZONE_MOVABLE, it does not allow to online partially-plugged memory blocks to ZONE_MOVABLE and will never consider such memory blocks when unplugging memory. This might be surprising

This patchset follows the main idea discussed at 2012 LSFMMS section: "Ballooning for transparent huge pages" -- http://lwn.net/Articles/490114/ to introduce the required changes to the virtio_balloon driver, as well as changes to the core compaction & migration bits, in order to allow memory balloon pages become movable within a guest. Rafael Aquini (4): mm: introduce compaction

This patchset follows the main idea discussed at 2012 LSFMMS section: "Ballooning for transparent huge pages" -- http://lwn.net/Articles/490114/ to introduce the required changes to the virtio_balloon driver, as well as changes to the core compaction & migration bits, in order to allow memory balloon pages become movable within a guest. Rafael Aquini (4): mm: introduce compaction