search for: exccess

...y cannot work with CMA. > Most of CMA memory space could be idle(ie, it could be used > for movable pages unless driver is using) but if driver(i.e., > zram) cannot migrate his page, that memory space could be > wasted. In our product which has big CMA memory, it reclaims > zones too exccessively although there are lots of free space > in CMA so system was very slow easily. > > To solve these problem, this patch try to add facility to > migrate non-lru pages via introducing new friend functions > of migratepage in address_space_operation and new page flags. > >...

...y cannot work with CMA. > Most of CMA memory space could be idle(ie, it could be used > for movable pages unless driver is using) but if driver(i.e., > zram) cannot migrate his page, that memory space could be > wasted. In our product which has big CMA memory, it reclaims > zones too exccessively although there are lots of free space > in CMA so system was very slow easily. > > To solve these problem, this patch try to add facility to > migrate non-lru pages via introducing new friend functions > of migratepage in address_space_operation and new page flags. > >...

...o fork easily which requires order-[2 or 3] allocations. > > Other pain point is that they cannot use CMA memory space so when OOM > kill happens, I can see many free pages in CMA area, which is not > memory efficient. In our product which has big CMA memory, it reclaims > zones too exccessively to allocate GPU and zram page although there are > lots of free space in CMA so system becomes very slow easily. > > To solve these problem, this patch tries to add facility to migrate > non-lru pages via introducing new functions and page flags to help > migration. I'm se...

...o fork easily which requires order-[2 or 3] allocations. > > Other pain point is that they cannot use CMA memory space so when OOM > kill happens, I can see many free pages in CMA area, which is not > memory efficient. In our product which has big CMA memory, it reclaims > zones too exccessively to allocate GPU and zram page although there are > lots of free space in CMA so system becomes very slow easily. But this isn't presently implemented for GPU drivers or for CMA, yes? What's the story there?

...y slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is that they cannot use CMA memory space so when OOM kill happens, I can see many free pages in CMA area, which is not memory efficient. In our product which has big CMA memory, it reclaims zones too exccessively to allocate GPU and zram page although there are lots of free space in CMA so system becomes very slow easily. To solve these problem, this patch tries to add facility to migrate non-lru pages via introducing new functions and page flags to help migration. struct address_space_operations {...

...y slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is that they cannot use CMA memory space so when OOM kill happens, I can see many free pages in CMA area, which is not memory efficient. In our product which has big CMA memory, it reclaims zones too exccessively to allocate GPU and zram page although there are lots of free space in CMA so system becomes very slow easily. To solve these problem, this patch tries to add facility to migrate non-lru pages via introducing new functions and page flags to help migration. struct address_space_operations {...

...y slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is that they cannot use CMA memory space so when OOM kill happens, I can see many free pages in CMA area, which is not memory efficient. In our product which has big CMA memory, it reclaims zones too exccessively to allocate GPU and zram page although there are lots of free space in CMA so system becomes very slow easily. To solve these problem, this patch tries to add facility to migrate non-lru pages via introducing new functions and page flags to help migration. struct address_space_operations {...

...y slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is that they cannot use CMA memory space so when OOM kill happens, I can see many free pages in CMA area, which is not memory efficient. In our product which has big CMA memory, it reclaims zones too exccessively to allocate GPU and zram page although there are lots of free space in CMA so system becomes very slow easily. To solve these problem, this patch tries to add facility to migrate non-lru pages via introducing new functions and page flags to help migration. struct address_space_operations {...

...er pain point is that they cannot work with CMA. Most of CMA memory space could be idle(ie, it could be used for movable pages unless driver is using) but if driver(i.e., zram) cannot migrate his page, that memory space could be wasted. In our product which has big CMA memory, it reclaims zones too exccessively although there are lots of free space in CMA so system was very slow easily. To solve these problem, this patch try to add facility to migrate non-lru pages via introducing new friend functions of migratepage in address_space_operation and new page flags. (isolate_page, putback_page) (PG_m...

...er pain point is that they cannot work with CMA. Most of CMA memory space could be idle(ie, it could be used for movable pages unless driver is using) but if driver(i.e., zram) cannot migrate his page, that memory space could be wasted. In our product which has big CMA memory, it reclaims zones too exccessively although there are lots of free space in CMA so system was very slow easily. To solve these problem, this patch try to add facility to migrate non-lru pages via introducing new friend functions of migratepage in address_space_operation and new page flags. (isolate_page, putback_page) (PG_m...

...y slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is that they cannot use CMA memory space so when OOM kill happens, I can see many free pages in CMA area, which is not memory efficient. In our product which has big CMA memory, it reclaims zones too exccessively to allocate GPU and zram page although there are lots of free space in CMA so system becomes very slow easily. To solve these problem, this patch tries to add facility to migrate non-lru pages via introducing new functions and page flags to help migration. struct address_space_operations {...

...y slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is that they cannot use CMA memory space so when OOM kill happens, I can see many free pages in CMA area, which is not memory efficient. In our product which has big CMA memory, it reclaims zones too exccessively to allocate GPU and zram page although there are lots of free space in CMA so system becomes very slow easily. To solve these problem, this patch tries to add facility to migrate non-lru pages via introducing new functions and page flags to help migration. struct address_space_operations {...

...er pain point is that they cannot work with CMA. Most of CMA memory space could be idle(ie, it could be used for movable pages unless driver is using) but if driver(i.e., zram) cannot migrate his page, that memory space could be wasted. In our product which has big CMA memory, it reclaims zones too exccessively although there are lots of free space in CMA so system was very slow easily. To solve these problem, this patch try to add facility to migrate non-lru pages via introducing new friend functions of migratepage in address_space_operation and new page flags. (isolate_page, putback_page) (PG_m...

...er pain point is that they cannot work with CMA. Most of CMA memory space could be idle(ie, it could be used for movable pages unless driver is using) but if driver(i.e., zram) cannot migrate his page, that memory space could be wasted. In our product which has big CMA memory, it reclaims zones too exccessively although there are lots of free space in CMA so system was very slow easily. To solve these problem, this patch try to add facility to migrate non-lru pages via introducing new friend functions of migratepage in address_space_operation and new page flags. (isolate_page, putback_page) (PG_m...

...y slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is that they cannot use CMA memory space so when OOM kill happens, I can see many free pages in CMA area, which is not memory efficient. In our product which has big CMA memory, it reclaims zones too exccessively to allocate GPU and zram page although there are lots of free space in CMA so system becomes very slow easily. To solve these problem, this patch tries to add facility to migrate non-lru pages via introducing new functions and page flags to help migration. struct address_space_operations {...

...y slow and even to fail to fork easily which requires order-[2 or 3] allocations. Other pain point is that they cannot use CMA memory space so when OOM kill happens, I can see many free pages in CMA area, which is not memory efficient. In our product which has big CMA memory, it reclaims zones too exccessively to allocate GPU and zram page although there are lots of free space in CMA so system becomes very slow easily. To solve these problem, this patch tries to add facility to migrate non-lru pages via introducing new functions and page flags to help migration. struct address_space_operations {...

...er pain point is that they cannot work with CMA. Most of CMA memory space could be idle(ie, it could be used for movable pages unless driver is using) but if driver(i.e., zram) cannot migrate his page, that memory space could be wasted. In our product which has big CMA memory, it reclaims zones too exccessively although there are lots of free space in CMA so system was very slow easily. To solve these problem, this patch try to add facility to migrate non-lru pages via introducing new friend functions of migratepage in address_space_operation and new page flags. (isolate_page, putback_page) (PG_m...

...er pain point is that they cannot work with CMA. Most of CMA memory space could be idle(ie, it could be used for movable pages unless driver is using) but if driver(i.e., zram) cannot migrate his page, that memory space could be wasted. In our product which has big CMA memory, it reclaims zones too exccessively although there are lots of free space in CMA so system was very slow easily. To solve these problem, this patch try to add facility to migrate non-lru pages via introducing new friend functions of migratepage in address_space_operation and new page flags. (isolate_page, putback_page) (PG_m...