Al Viro writes:
> On Wed, Apr 09, 2014 at 06:53:23PM +0100, Al Viro wrote:
>
>> For starters, put that ext4 on top of dm-raid or dm-multipath. That alone
>> will very likely push you over the top.
>>
>> Keep in mind, BTW, that you do not have full 8K to play with - there's
>> struct thread_info
On Wed, Apr 09, 2014 at 10:32:14AM -0700, Eric W. Biederman wrote:
> Al Viro writes:
>
> > On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:
> >
> >> > When renaming or unlinking directory entries that are not mountpoints
> >> > no additional locks are taken so no performance differences c
On Wed, Apr 09, 2014 at 06:53:23PM +0100, Al Viro wrote:
> For starters, put that ext4 on top of dm-raid or dm-multipath. That alone
> will very likely push you over the top.
>
> Keep in mind, BTW, that you do not have full 8K to play with - there's
> struct thread_info that should not be steppe
On Wed, Apr 09, 2014 at 10:32:14AM -0700, Eric W. Biederman wrote:
> For resolving a deeply nested symlink that hits the limit of 8 nested
> symlinks, I find 4688 bytes left on the stack. Which means we use
> roughly 3504 bytes of stack when stating a deeply nested symlink.
>
> For umount I had
Al Viro writes:
> On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:
>
>> > When renaming or unlinking directory entries that are not mountpoints
>> > no additional locks are taken so no performance differences can result,
>> > and my benchmark reflected that.
>>
>> It also means that d_in
Al Viro writes:
> On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:
>
>> > When renaming or unlinking directory entries that are not mountpoints
>> > no additional locks are taken so no performance differences can result,
>> > and my benchmark reflected that.
>>
>> It also means that d_in
On Wed, Apr 09, 2014 at 03:30:27AM +0100, Al Viro wrote:
> > When renaming or unlinking directory entries that are not mountpoints
> > no additional locks are taken so no performance differences can result,
> > and my benchmark reflected that.
>
> It also means that d_invalidate() now might trigg
On Tue, Apr 08, 2014 at 05:21:32PM -0700, Eric W. Biederman wrote:
> This set of changes has been reviewed and been sitting idle for the last
> 6 weeks. In that time the vfs has slightly shifted under me the new
> version of rename and the mount hash list becoming a hlist. None of
> those change
Linus,
Please pull the for-linus branch from the git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git
for-linus
HEAD: 0d7d90f86f83f29a442b37c78172870f8ee28c58 proc: Update
proc_flush_task_mnt to use d_invalidate
My apologies for sending this pull request
9 matches
Mail list logo
