Re: [PATCH v13 4/5] mm: support reporting free page blocks
From: Wei Wang
Date: Fri Aug 04 2017 - 04:13:05 EST
On 08/04/2017 03:53 PM, Michal Hocko wrote:
On Fri 04-08-17 00:02:01, Michael S. Tsirkin wrote:
On Thu, Aug 03, 2017 at 03:20:09PM +0000, Wang, Wei W wrote:
No, I this should be strictly non-modifying API.
On Thursday, August 3, 2017 9:51 PM, Michal Hocko:
The tricky part is when you need to drop the lock and
As I've said earlier. Start simple optimize incrementally with some numbers to
OK. Let's start with the simple implementation as you suggested.
justify a more subtle code.
then restart because the device is busy. Would it maybe
make sense to rotate the list so that new head
will consist of pages not yet sent to device?
Just get the context here for discussion:
visit(opaque2, pfn, 1<<order);
The concern is that the callback may cause the lock be
taken too long.
I think here we can have two options:
- Option 1: Put a Note for the callback: the callback function
should not block and it should finish as soon as possible.
(when implementing an interrupt handler, we also have
such similar rules in mind, right?).
For our use case, the callback just puts the reported page
block to the ring, then returns. If the ring is full as the host
is busy, then I think it should skip this one, and just return.
A. This is an optimization feature, losing a couple of free
pages to report isn't that important;
B. In reality, I think it's uncommon to see this ring getting
full (I didn't observe ring full in the tests), since the host
(consumer) is notified to take out the page block right
after it is added.
- Option 2: Put the callback function outside the lock
What's input into the callback is just a pfn, and the callback
won't access the corresponding pages. So, I still think it won't
be an issue no matter what status of the pages is after they
are reported (even they doesn't exit due to hot-remove).
What would you guys think?