* a question of split_huge_page @ 2020-07-09 15:11 Alex Shi 2020-07-09 15:50 ` Matthew Wilcox 0 siblings, 1 reply; 12+ messages in thread From: Alex Shi @ 2020-07-09 15:11 UTC (permalink / raw) To: Johannes Weiner, Kirill A. Shutemov, Matthew Wilcox, Linux-MM, linux-kernel, Hugh Dickins Hi Kirill & Matthew, In the func call chain, from split_huge_page() to lru_add_page_tail(), Seems tail pages are added to lru list at line 963, but in this scenario the head page has no lru bit and isn't set the bit later. Why we do this? or do I miss sth? Many Thanks Alex 938 void lru_add_page_tail(struct page *page, struct page *page_tail, 939 struct lruvec *lruvec, struct list_head *list) 940 { 941 VM_BUG_ON_PAGE(!PageHead(page), page); 942 VM_BUG_ON_PAGE(PageCompound(page_tail), page); 943 VM_BUG_ON_PAGE(PageLRU(page_tail), page); 944 lockdep_assert_held(&lruvec_pgdat(lruvec)->lru_lock); 945 946 if (!list) 947 SetPageLRU(page_tail); 948 949 if (likely(PageLRU(page))) 950 list_add_tail(&page_tail->lru, &page->lru); 951 else if (list) { 952 /* page reclaim is reclaiming a huge page */ 953 get_page(page_tail); 954 list_add_tail(&page_tail->lru, list); 955 } else { 956 /* 957 * Head page has not yet been counted, as an hpage, 958 * so we must account for each subpage individually. 959 * 960 * Put page_tail on the list at the correct position 961 * so they all end up in order. 962 */ 963 add_page_to_lru_list_tail(page_tail, lruvec, 964 page_lru(page_tail)); 965 } 966 } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-09 15:11 a question of split_huge_page Alex Shi @ 2020-07-09 15:50 ` Matthew Wilcox 2020-07-09 16:07 ` Kirill A. Shutemov 0 siblings, 1 reply; 12+ messages in thread From: Matthew Wilcox @ 2020-07-09 15:50 UTC (permalink / raw) To: Alex Shi Cc: Johannes Weiner, Kirill A. Shutemov, Linux-MM, linux-kernel, Hugh Dickins On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: > Hi Kirill & Matthew, > > In the func call chain, from split_huge_page() to lru_add_page_tail(), > Seems tail pages are added to lru list at line 963, but in this scenario > the head page has no lru bit and isn't set the bit later. Why we do this? > or do I miss sth? I don't understand how we get to split_huge_page() with a page that's not on an LRU list. Both anonymous and page cache pages should be on an LRU list. What am I missing? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-09 15:50 ` Matthew Wilcox @ 2020-07-09 16:07 ` Kirill A. Shutemov 2020-07-10 4:51 ` Alex Shi 0 siblings, 1 reply; 12+ messages in thread From: Kirill A. Shutemov @ 2020-07-09 16:07 UTC (permalink / raw) To: Matthew Wilcox Cc: Alex Shi, Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins On Thu, Jul 09, 2020 at 04:50:02PM +0100, Matthew Wilcox wrote: > On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: > > Hi Kirill & Matthew, > > > > In the func call chain, from split_huge_page() to lru_add_page_tail(), > > Seems tail pages are added to lru list at line 963, but in this scenario > > the head page has no lru bit and isn't set the bit later. Why we do this? > > or do I miss sth? > > I don't understand how we get to split_huge_page() with a page that's > not on an LRU list. Both anonymous and page cache pages should be on > an LRU list. What am I missing? Right, and it's never got removed from LRU during the split. The tail pages have to be added to LRU because they now separate from the tail page. -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-09 16:07 ` Kirill A. Shutemov @ 2020-07-10 4:51 ` Alex Shi 2020-07-10 5:28 ` Mika Penttilä 2020-07-10 10:33 ` Kirill A. Shutemov 0 siblings, 2 replies; 12+ messages in thread From: Alex Shi @ 2020-07-10 4:51 UTC (permalink / raw) To: Kirill A. Shutemov, Matthew Wilcox Cc: Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins 在 2020/7/10 上午12:07, Kirill A. Shutemov 写道: > On Thu, Jul 09, 2020 at 04:50:02PM +0100, Matthew Wilcox wrote: >> On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: >>> Hi Kirill & Matthew, >>> >>> In the func call chain, from split_huge_page() to lru_add_page_tail(), >>> Seems tail pages are added to lru list at line 963, but in this scenario >>> the head page has no lru bit and isn't set the bit later. Why we do this? >>> or do I miss sth? >> >> I don't understand how we get to split_huge_page() with a page that's >> not on an LRU list. Both anonymous and page cache pages should be on >> an LRU list. What am I missing?> Thanks a lot for quick reply! What I am confusing is the call chain: __iommu_dma_alloc_pages() to split_huge_page(), in the func, splited page, page = alloc_pages_node(nid, alloc_flags, order); And if the pages were added into lru, they maybe reclaimed and lost, that would be a panic bug. But in fact, this never happened for long time. Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmtests in kselftest. > Right, and it's never got removed from LRU during the split. The tail > pages have to be added to LRU because they now separate from the tail > page. > According to the explaination, looks like we could remove the code path, since it's never got into. (base on my v15 patchset). Any comments? Thanks Alex diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 7c52c5228aab..c28409509ad3 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -2357,17 +2357,6 @@ static void lru_add_page_tail(struct page *head, struct page *page_tail, if (!list) SetPageLRU(page_tail); if (likely(PageLRU(head))) list_add_tail(&page_tail->lru, &head->lru); else if (list) { /* page reclaim is reclaiming a huge page */ get_page(page_tail); list_add_tail(&page_tail->lru, list); - } else { - /* - * Head page has not yet been counted, as an hpage, - * so we must account for each subpage individually. - * - * Put page_tail on the list at the correct position - * so they all end up in order. - */ - VM_BUG_ON_PAGE(1, head); - add_page_to_lru_list_tail(page_tail, lruvec, - page_lru(page_tail)); } } ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-10 4:51 ` Alex Shi @ 2020-07-10 5:28 ` Mika Penttilä 2020-07-10 7:00 ` Alex Shi 2020-07-10 9:34 ` Alex Shi 2020-07-10 10:33 ` Kirill A. Shutemov 1 sibling, 2 replies; 12+ messages in thread From: Mika Penttilä @ 2020-07-10 5:28 UTC (permalink / raw) To: Alex Shi, Kirill A. Shutemov, Matthew Wilcox Cc: Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins [-- Attachment #1: Type: text/plain, Size: 2861 bytes --] On 10.7.2020 7.51, Alex Shi wrote: > > 在 2020/7/10 上午12:07, Kirill A. Shutemov 写道: >> On Thu, Jul 09, 2020 at 04:50:02PM +0100, Matthew Wilcox wrote: >>> On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: >>>> Hi Kirill & Matthew, >>>> >>>> In the func call chain, from split_huge_page() to lru_add_page_tail(), >>>> Seems tail pages are added to lru list at line 963, but in this scenario >>>> the head page has no lru bit and isn't set the bit later. Why we do this? >>>> or do I miss sth? >>> I don't understand how we get to split_huge_page() with a page that's >>> not on an LRU list. Both anonymous and page cache pages should be on >>> an LRU list. What am I missing?> > > Thanks a lot for quick reply! > What I am confusing is the call chain: __iommu_dma_alloc_pages() > to split_huge_page(), in the func, splited page, > page = alloc_pages_node(nid, alloc_flags, order); > And if the pages were added into lru, they maybe reclaimed and lost, > that would be a panic bug. But in fact, this never happened for long time. > Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmtests In __iommu_dma_alloc_pages, after split_huge_page(), who is taking a reference on tail pages? Seems tail pages are freed and the function errornously returns them in pages[] array for use? > in kselftest. > >> Right, and it's never got removed from LRU during the split. The tail >> pages have to be added to LRU because they now separate from the tail >> page. >> > According to the explaination, looks like we could remove the code path, > since it's never got into. (base on my v15 patchset). Any comments? > > Thanks > Alex > > diff --git a/mm/huge_memory.c b/mm/huge_memory.c > index 7c52c5228aab..c28409509ad3 100644 > --- a/mm/huge_memory.c > +++ b/mm/huge_memory.c > @@ -2357,17 +2357,6 @@ static void lru_add_page_tail(struct page *head, struct page *page_tail, > if (!list) > SetPageLRU(page_tail); > > if (likely(PageLRU(head))) > list_add_tail(&page_tail->lru, &head->lru); > else if (list) { > /* page reclaim is reclaiming a huge page */ > get_page(page_tail); > list_add_tail(&page_tail->lru, list); > - } else { > - /* > - * Head page has not yet been counted, as an hpage, > - * so we must account for each subpage individually. > - * > - * Put page_tail on the list at the correct position > - * so they all end up in order. > - */ > - VM_BUG_ON_PAGE(1, head); > - add_page_to_lru_list_tail(page_tail, lruvec, > - page_lru(page_tail)); > } > } [-- Attachment #2: pEpkey.asc --] [-- Type: application/pgp-keys, Size: 3157 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-10 5:28 ` Mika Penttilä @ 2020-07-10 7:00 ` Alex Shi 2020-07-10 7:22 ` Mika Penttilä 2020-07-10 9:34 ` Alex Shi 1 sibling, 1 reply; 12+ messages in thread From: Alex Shi @ 2020-07-10 7:00 UTC (permalink / raw) To: Mika Penttilä, Kirill A. Shutemov, Matthew Wilcox Cc: Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins 在 2020/7/10 下午1:28, Mika Penttilä 写道: >> Thanks a lot for quick reply! >> What I am confusing is the call chain: __iommu_dma_alloc_pages() >> to split_huge_page(), in the func, splited page, >> page = alloc_pages_node(nid, alloc_flags, order); >> And if the pages were added into lru, they maybe reclaimed and lost, >> that would be a panic bug. But in fact, this never happened for long time. >> Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmtests > > In __iommu_dma_alloc_pages, after split_huge_page(), who is taking a > reference on tail pages? Seems tail pages are freed and the function > errornously returns them in pages[] array for use? > Why you say so? It looks like the tail page returned and be used pages = __iommu_dma_alloc_pages() in iommu_dma_alloc_remap() and still on node's lru. Is this right? thanks! ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-10 7:00 ` Alex Shi @ 2020-07-10 7:22 ` Mika Penttilä 0 siblings, 0 replies; 12+ messages in thread From: Mika Penttilä @ 2020-07-10 7:22 UTC (permalink / raw) To: Alex Shi, Kirill A. Shutemov, Matthew Wilcox Cc: Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins [-- Attachment #1: Type: text/plain, Size: 1126 bytes --] On 10.7.2020 10.00, Alex Shi wrote: > > 在 2020/7/10 下午1:28, Mika Penttilä 写道: >>> Thanks a lot for quick reply! >>> What I am confusing is the call chain: __iommu_dma_alloc_pages() >>> to split_huge_page(), in the func, splited page, >>> page = alloc_pages_node(nid, alloc_flags, order); >>> And if the pages were added into lru, they maybe reclaimed and lost, >>> that would be a panic bug. But in fact, this never happened for long time. >>> Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmtests >> In __iommu_dma_alloc_pages, after split_huge_page(), who is taking a >> reference on tail pages? Seems tail pages are freed and the function >> errornously returns them in pages[] array for use? >> > Why you say so? It looks like the tail page returned and be used > pages = __iommu_dma_alloc_pages() in iommu_dma_alloc_remap() > and still on node's lru. Is this right? > > thanks! IMHO they are new pages coming from alloc_pages_node() so they are not on lru. And split_huge_page() frees not pinned tail pages again to page allocator. Thanks, Mika [-- Attachment #2: pEpkey.asc --] [-- Type: application/pgp-keys, Size: 3157 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-10 5:28 ` Mika Penttilä 2020-07-10 7:00 ` Alex Shi @ 2020-07-10 9:34 ` Alex Shi 2020-07-10 12:56 ` Joerg Roedel 2020-07-10 17:29 ` Yang Shi 1 sibling, 2 replies; 12+ messages in thread From: Alex Shi @ 2020-07-10 9:34 UTC (permalink / raw) To: Mika Penttilä, Kirill A. Shutemov, Matthew Wilcox Cc: Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins, Joerg Roedel, iommu 在 2020/7/10 下午1:28, Mika Penttilä 写道: > > > On 10.7.2020 7.51, Alex Shi wrote: >> >> 在 2020/7/10 上午12:07, Kirill A. Shutemov 写道: >>> On Thu, Jul 09, 2020 at 04:50:02PM +0100, Matthew Wilcox wrote: >>>> On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: >>>>> Hi Kirill & Matthew, >>>>> >>>>> In the func call chain, from split_huge_page() to lru_add_page_tail(), >>>>> Seems tail pages are added to lru list at line 963, but in this scenario >>>>> the head page has no lru bit and isn't set the bit later. Why we do this? >>>>> or do I miss sth? >>>> I don't understand how we get to split_huge_page() with a page that's >>>> not on an LRU list. Both anonymous and page cache pages should be on >>>> an LRU list. What am I missing?> >> >> Thanks a lot for quick reply! >> What I am confusing is the call chain: __iommu_dma_alloc_pages() >> to split_huge_page(), in the func, splited page, >> page = alloc_pages_node(nid, alloc_flags, order); >> And if the pages were added into lru, they maybe reclaimed and lost, >> that would be a panic bug. But in fact, this never happened for long time. >> Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmtests > > > In __iommu_dma_alloc_pages, after split_huge_page(), who is taking a > reference on tail pages? Seems tail pages are freed and the function > errornously returns them in pages[] array for use? > CC Joerg and iommu list, That's a good question. seems the split_huge_page was never triggered here, since the func would check the PageLock first. and have page->mapping and PageAnon check, any of them couldn't be matched for the alloced page. Hi Joerg, would you like look into this? do we still need the split_huge_page() here? Thanks Alex int split_huge_page_to_list(struct page *page, struct list_head *list) { struct page *head = compound_head(page); struct deferred_split *ds_queue = get_deferred_split_queue(head); struct anon_vma *anon_vma = NULL; struct address_space *mapping = NULL; int count, mapcount, extra_pins, ret; pgoff_t end; VM_BUG_ON_PAGE(is_huge_zero_page(head), head); VM_BUG_ON_PAGE(!PageLocked(head), head); <== > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-10 9:34 ` Alex Shi @ 2020-07-10 12:56 ` Joerg Roedel 2020-07-10 17:29 ` Yang Shi 1 sibling, 0 replies; 12+ messages in thread From: Joerg Roedel @ 2020-07-10 12:56 UTC (permalink / raw) To: Alex Shi, Robin Murphy Cc: Mika Penttilä, Kirill A. Shutemov, Matthew Wilcox, Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins, iommu Adding Robin. On Fri, Jul 10, 2020 at 05:34:52PM +0800, Alex Shi wrote: > 在 2020/7/10 下午1:28, Mika Penttilä 写道: > > > > > > On 10.7.2020 7.51, Alex Shi wrote: > >> > >> 在 2020/7/10 上午12:07, Kirill A. Shutemov 写道: > >>> On Thu, Jul 09, 2020 at 04:50:02PM +0100, Matthew Wilcox wrote: > >>>> On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: > >>>>> Hi Kirill & Matthew, > >>>>> > >>>>> In the func call chain, from split_huge_page() to lru_add_page_tail(), > >>>>> Seems tail pages are added to lru list at line 963, but in this scenario > >>>>> the head page has no lru bit and isn't set the bit later. Why we do this? > >>>>> or do I miss sth? > >>>> I don't understand how we get to split_huge_page() with a page that's > >>>> not on an LRU list. Both anonymous and page cache pages should be on > >>>> an LRU list. What am I missing?> > >> > >> Thanks a lot for quick reply! > >> What I am confusing is the call chain: __iommu_dma_alloc_pages() > >> to split_huge_page(), in the func, splited page, > >> page = alloc_pages_node(nid, alloc_flags, order); > >> And if the pages were added into lru, they maybe reclaimed and lost, > >> that would be a panic bug. But in fact, this never happened for long time. > >> Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmtests > > > > > > In __iommu_dma_alloc_pages, after split_huge_page(), who is taking a > > reference on tail pages? Seems tail pages are freed and the function > > errornously returns them in pages[] array for use? > > > > CC Joerg and iommu list, > > That's a good question. seems the split_huge_page was never triggered here, > since the func would check the PageLock first. and have page->mapping and PageAnon > check, any of them couldn't be matched for the alloced page. > > Hi Joerg, > would you like look into this? do we still need the split_huge_page() here? > > Thanks > Alex > > int split_huge_page_to_list(struct page *page, struct list_head *list) > { > struct page *head = compound_head(page); > struct deferred_split *ds_queue = get_deferred_split_queue(head); > struct anon_vma *anon_vma = NULL; > struct address_space *mapping = NULL; > int count, mapcount, extra_pins, ret; > pgoff_t end; > > VM_BUG_ON_PAGE(is_huge_zero_page(head), head); > VM_BUG_ON_PAGE(!PageLocked(head), head); <== > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-10 9:34 ` Alex Shi 2020-07-10 12:56 ` Joerg Roedel @ 2020-07-10 17:29 ` Yang Shi 1 sibling, 0 replies; 12+ messages in thread From: Yang Shi @ 2020-07-10 17:29 UTC (permalink / raw) To: Alex Shi Cc: Mika Penttilä, Kirill A. Shutemov, Matthew Wilcox, Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins, Joerg Roedel, iommu On Fri, Jul 10, 2020 at 2:35 AM Alex Shi <alex.shi@linux.alibaba.com> wrote: > > 在 2020/7/10 下午1:28, Mika Penttilä 写道: > > > > > > On 10.7.2020 7.51, Alex Shi wrote: > >> > >> 在 2020/7/10 上午12:07, Kirill A. Shutemov 写道: > >>> On Thu, Jul 09, 2020 at 04:50:02PM +0100, Matthew Wilcox wrote: > >>>> On Thu, Jul 09, 2020 at 11:11:11PM +0800, Alex Shi wrote: > >>>>> Hi Kirill & Matthew, > >>>>> > >>>>> In the func call chain, from split_huge_page() to lru_add_page_tail(), > >>>>> Seems tail pages are added to lru list at line 963, but in this scenario > >>>>> the head page has no lru bit and isn't set the bit later. Why we do this? > >>>>> or do I miss sth? > >>>> I don't understand how we get to split_huge_page() with a page that's > >>>> not on an LRU list. Both anonymous and page cache pages should be on > >>>> an LRU list. What am I missing?> > >> > >> Thanks a lot for quick reply! > >> What I am confusing is the call chain: __iommu_dma_alloc_pages() > >> to split_huge_page(), in the func, splited page, > >> page = alloc_pages_node(nid, alloc_flags, order); > >> And if the pages were added into lru, they maybe reclaimed and lost, > >> that would be a panic bug. But in fact, this never happened for long time. > >> Also I put a BUG() at the line, it's nevre triggered in ltp, and run_vmtests > > > > > > In __iommu_dma_alloc_pages, after split_huge_page(), who is taking a > > reference on tail pages? Seems tail pages are freed and the function > > errornously returns them in pages[] array for use? > > > > CC Joerg and iommu list, > > That's a good question. seems the split_huge_page was never triggered here, > since the func would check the PageLock first. and have page->mapping and PageAnon > check, any of them couldn't be matched for the alloced page. > > Hi Joerg, > would you like look into this? do we still need the split_huge_page() here? I think this is the same problem which has been discussed a couple of weeks ago. Please refer to: https://lore.kernel.org/linux-mm/20200619001938.GA135965@carbon.dhcp.thefacebook.com/ I think the conclusion is split_huge_page() can't be used in this path at all. But we didn't reach a fix yet. > > Thanks > Alex > > int split_huge_page_to_list(struct page *page, struct list_head *list) > { > struct page *head = compound_head(page); > struct deferred_split *ds_queue = get_deferred_split_queue(head); > struct anon_vma *anon_vma = NULL; > struct address_space *mapping = NULL; > int count, mapcount, extra_pins, ret; > pgoff_t end; > > VM_BUG_ON_PAGE(is_huge_zero_page(head), head); > VM_BUG_ON_PAGE(!PageLocked(head), head); <== > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-10 4:51 ` Alex Shi 2020-07-10 5:28 ` Mika Penttilä @ 2020-07-10 10:33 ` Kirill A. Shutemov 2020-07-10 14:23 ` Alex Shi 1 sibling, 1 reply; 12+ messages in thread From: Kirill A. Shutemov @ 2020-07-10 10:33 UTC (permalink / raw) To: Alex Shi Cc: Matthew Wilcox, Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins On Fri, Jul 10, 2020 at 12:51:58PM +0800, Alex Shi wrote: > > > 在 2020/7/10 上午12:07, Kirill A. Shutemov 写道: > > Right, and it's never got removed from LRU during the split. The tail > > pages have to be added to LRU because they now separate from the tail > > page. > > > According to the explaination, looks like we could remove the code path, > since it's never got into. (base on my v15 patchset). Any comments? Yes. But why? It's reasonable failsafe that gives chance to recover if something goes wrong. -- Kirill A. Shutemov ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: a question of split_huge_page 2020-07-10 10:33 ` Kirill A. Shutemov @ 2020-07-10 14:23 ` Alex Shi 0 siblings, 0 replies; 12+ messages in thread From: Alex Shi @ 2020-07-10 14:23 UTC (permalink / raw) To: Kirill A. Shutemov Cc: Matthew Wilcox, Johannes Weiner, Linux-MM, linux-kernel, Hugh Dickins 在 2020/7/10 下午6:33, Kirill A. Shutemov 写道: > On Fri, Jul 10, 2020 at 12:51:58PM +0800, Alex Shi wrote: >> >> >> 在 2020/7/10 上午12:07, Kirill A. Shutemov 写道: >>> Right, and it's never got removed from LRU during the split. The tail >>> pages have to be added to LRU because they now separate from the tail >>> page. >>> >> According to the explaination, looks like we could remove the code path, >> since it's never got into. (base on my v15 patchset). Any comments? > > Yes. But why? It's reasonable failsafe that gives chance to recover if > something goes wrong. > Hi Kirill, Sorry, I didn't get your points. IMHO, this fallback cann't work well, since the head page isn't and shouldn't be added to lru. like the iommu issue if a dma page added into lru list, it may be reclaim and lost. So, sorry, I still don't know how this path could fix some wrong. Thanks Alex ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-07-10 17:29 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-07-09 15:11 a question of split_huge_page Alex Shi 2020-07-09 15:50 ` Matthew Wilcox 2020-07-09 16:07 ` Kirill A. Shutemov 2020-07-10 4:51 ` Alex Shi 2020-07-10 5:28 ` Mika Penttilä 2020-07-10 7:00 ` Alex Shi 2020-07-10 7:22 ` Mika Penttilä 2020-07-10 9:34 ` Alex Shi 2020-07-10 12:56 ` Joerg Roedel 2020-07-10 17:29 ` Yang Shi 2020-07-10 10:33 ` Kirill A. Shutemov 2020-07-10 14:23 ` Alex Shi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).