Re: [PATCH 0/3] retry slab allocation after first failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 9 Jan 2013, Glauber Costa wrote:

> I will certainly look into that. But I still fear that regardless of
> what we do here, the logic is still "retry the whole thing again". We
> already know there is no free page, and without inspecting the internals
> of the allocator it is hard to know where to start looking - therefore,
> we need to retry from the start.

The slow paths functions in the allocator can performa the retry of
"the whole thing".

slab's fallback alloc does precisely that. What you need to do there is to
just go back to the retry: label if the attempt to grow the slab fails.

slub's __slab_alloc() can use a similar approach by looping back to the
redo: label.

Either one is trivial to implement.

> If it fails again, we will recurse to the same oom state. This means we
> need to keep track of the state, at least, in which retry we are. If I
> can keep it local, fine, I will argue no further. But if this state
> needs to spread throughout the other paths, I think we have a lot more
> to lose.

Adding another state variable is not that intrusive in fallback_alloc or
__slab_alloc.

Alternatively we could extract the functionality to check the current
queues from the allocator and call them twice from the slow paths.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux