[lkml]   [2017]   [Oct]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 2/2] vfs: grab the lock instead of blocking in __fd_install during resizing
On Wed, Oct 04, 2017 at 07:00:40AM -0700, Eric Dumazet wrote:
> On Wed, Oct 4, 2017 at 6:55 AM, Matthew Wilcox <> wrote:
> > Any chance you could review the patches from Sandhya that make this entire
> > codepath obsolete?
> >
> >
> >
> Hmm...
> 18 files changed, 578 insertions(+), 585 deletions(-)
> Frankly I need to be convinced with solid performance numbers before I
> am taking a look at this series.

I was hoping you'd help us get some solid performance numbers ... you
seem to have workloads available to you that help find weaknesses in

The number of lines inserted is a bit of a red herring. Over 100 are in
the test suite (you surely aren't going to review those) and another ~300
are adding enhancements to the IDR & radix tree that should be useful
for other users (eg I think I have a way to speed up writing out dirty
pages by using get_tag_batch()).

> I do not believe an IDR will be faster than current implementation, so
> I am not quite convinced at this moment.

I don't think it should be significantly different in performance. Let's
look at the layout of data for a typical bash shell (fds 0-2 and 255 open).

Current implementation:

files_struct -> fdt -> fd -> struct file


files_struct -> radix node (shift 6) -> radix node (shift 0) -> struct file

In either case, it's the same number of dependent loads. It'll start
to look worse for the radix tree above 4096 open fds in a given process.

 \ /
  Last update: 2017-10-04 17:00    [W:0.049 / U:3.644 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site