On Wed, Dec 09, 2020 at 11:25:31AM +0100, Vlastimil Babka wrote:
> On 12/9/20 10:28 AM, Oscar Salvador wrote:
> > Currently, we return -EIO when we fail to migrate the page.
> >
> > Migrations' failures are rather transient as they can happen due to
> > several reasons, e.g: high page refcount
On Wed, Dec 09, 2020 at 10:59:04AM +0100, David Hildenbrand wrote:
> On 09.12.20 10:28, Oscar Salvador wrote:
> Do we expect callers to retry immediately? -EAGAIN might make also
> sense. But -EBUSY is an obvious improvement. Do we have callers relying
> on this behavior?
Not really, unless
On 12/9/20 10:28 AM, Oscar Salvador wrote:
> Currently, we return -EIO when we fail to migrate the page.
>
> Migrations' failures are rather transient as they can happen due to
> several reasons, e.g: high page refcount bump, mapping->migrate_page
> failing etc.
> All meaning that at that time
On 09.12.20 10:28, Oscar Salvador wrote:
> Currently, we return -EIO when we fail to migrate the page.
>
> Migrations' failures are rather transient as they can happen due to
> several reasons, e.g: high page refcount bump, mapping->migrate_page
> failing etc.
> All meaning that at that time the
On Wed, Dec 09, 2020 at 10:28:18AM +0100, Oscar Salvador wrote:
> Currently, we return -EIO when we fail to migrate the page.
>
> Migrations' failures are rather transient as they can happen due to
> several reasons, e.g: high page refcount bump, mapping->migrate_page
> failing etc.
> All meaning
Currently, we return -EIO when we fail to migrate the page.
Migrations' failures are rather transient as they can happen due to
several reasons, e.g: high page refcount bump, mapping->migrate_page
failing etc.
All meaning that at that time the page could not be migrated, but
that has nothing to
6 matches
Mail list logo
