On Thu, Jun 25, 2020 at 4:42 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Wed, Jun 24, 2020 at 08:14:17PM +0100, Chris Wilson wrote: > > A side effect of the LRU shrinker not being dma aware is that we will > > often attempt to perform direct reclaim on the persistent group of dma > > pages while continuing to use the dma HW (an issue as the HW may already > > be actively waiting for the next user request), and even attempt to > > reclaim a partially allocated dma object in order to satisfy pinning > > the next user page for that object. > > > > It is to be expected that such pages are made available for reclaim at > > the end of the dma operation [unpin_user_pages()], and for truly > > longterm pins to be proactively recovered via device specific shrinkers > > [i.e. stop the HW, allow the pages to be returned to the system, and > > then compete again for the memory]. > > Why are DMA pinned pages still on the LRU list at all? I never got an > answer to this that made sense to me. By definition, a page which is > pinned for DMA is being accessed, and needs to at the very least change > position on the LRU list, so just take it off the list when DMA-pinned > and put it back on the list when DMA-unpinned. Sounds reasonable to me. In the earlier email I suggested skip isolate dma pinned page in scan phase, but if they are long term pinned, it seems preferred to put them on the unevictable lru IMHO. > > This overly complex lease stuff must have some reason for existing, but > I still don't get it. >
