From: Nick Piggin <npiggin@suse.de> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Al Viro <viro@ZenIV.linux.org.uk>, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>, Tejun Heo <tj@kernel.org>, Alexey Dobriyan <adobriyan@gmail.com>, Linus Torvalds <torvalds@linux-foundation.org>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Greg Kroah-Hartman <gregkh@suse.de>, Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, "Eric W. Biederman" <ebiederm@aristanetworks.com> Subject: Re: [PATCH 03/23] vfs: Generalize the file_list Date: Tue, 9 Jun 2009 12:38:32 +0200 [thread overview] Message-ID: <20090609103832.GI14820@wotan.suse.de> (raw) In-Reply-To: <m1ab4m5vbs.fsf@fess.ebiederm.org> On Fri, Jun 05, 2009 at 12:33:59PM -0700, Eric W. Biederman wrote: > Nick Piggin <npiggin@suse.de> writes: > > >> +static inline void file_list_unlock(struct file_list *files) > >> +{ > >> + spin_unlock(&files->lock); > >> +} > > > > I don't really like this. It's just a list head. Get rid of > > all these wrappers and crap I'd say. In fact, starting with my > > patch to unexport files_lock and remove these wrappers would > > be reasonable, wouldn't it? > > I don't really mind killing the wrappers. > > I do mind your patch because it makes the list going through > the tty's something very different. In my view of the world > that is the only use case is what I'm working to move up more > into the vfs layer. So orphaning it seems wrong. My patch doesn't orphan it, it just makes the locking more explicit and that's all so it should be easier to work with. I just mean start with my patch and you could change things as needed. > > Increasing the size of the struct inode by 24 bytes hurts. > > Even when you decrapify it and can reuse i_lock or something, > > then it is still 16 bytes on 64-bit. > > We can get it even smaller if we make it an hlist. A hlist_head is > only a single pointer. This size growth appears to be one of the > biggest weakness of the code. 8 bytes would be a lot better than 24. > > I haven't looked through all the patches... but this is to > > speed up a slowpath operation, isn't it? Or does revoke > > need to be especially performant? > > This was more about simplicity rather than performance. The > performance gain is using a per inode lock instead of a global lock. > Which keeps cache lines from bouncing. Yes but we already have such a global lock which has been OK until now. Granted that some users are running into these locks, but fine graining them can be considered independently I think. So using per-sb lists of files and not bloating struct inode any more could be a less controversial step for you. > > So this patch is purely a perofrmance improvement? Then I think > > it needs to be justified with numbers and the downsides (bloating > > struct inode in particulra) to be changelogged. > > Certainly the cost. > > One of the things I have discovered since I wrote this patch is the > i_devices list. Which means we don't necessarily need to have heads > in places other than struct inode. A character device driver (aka the > tty code) can walk it's inode list and from each inode walk the file > list. I need to check the locking on that one. > > If that simplification works we can move all maintenance of the file > list into the vfs and not need a separate file list concept. I will > take a look. Thanks, Nick
WARNING: multiple messages have this Message-ID (diff)
From: Nick Piggin <npiggin@suse.de> To: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Al Viro <viro@ZenIV.linux.org.uk>, linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>, Tejun Heo <tj@kernel.org>, Alexey Dobriyan <adobriyan@gmail.com>, Linus Torvalds <torvalds@linux-foundation.org>, Alan Cox <alan@lxorguk.ukuu.org.uk>, Greg Kroah-Hartman <gregkh@suse.de>, Andrew Morton <akpm@linux-foundation.org>, Christoph Hellwig <hch@infradead.org>, "Eric W. Biederman" <ebiederm@aristanetworks.com> Subject: Re: [PATCH 03/23] vfs: Generalize the file_list Date: Tue, 9 Jun 2009 12:38:32 +0200 [thread overview] Message-ID: <20090609103832.GI14820@wotan.suse.de> (raw) In-Reply-To: <m1ab4m5vbs.fsf@fess.ebiederm.org> On Fri, Jun 05, 2009 at 12:33:59PM -0700, Eric W. Biederman wrote: > Nick Piggin <npiggin@suse.de> writes: > > >> +static inline void file_list_unlock(struct file_list *files) > >> +{ > >> + spin_unlock(&files->lock); > >> +} > > > > I don't really like this. It's just a list head. Get rid of > > all these wrappers and crap I'd say. In fact, starting with my > > patch to unexport files_lock and remove these wrappers would > > be reasonable, wouldn't it? > > I don't really mind killing the wrappers. > > I do mind your patch because it makes the list going through > the tty's something very different. In my view of the world > that is the only use case is what I'm working to move up more > into the vfs layer. So orphaning it seems wrong. My patch doesn't orphan it, it just makes the locking more explicit and that's all so it should be easier to work with. I just mean start with my patch and you could change things as needed. > > Increasing the size of the struct inode by 24 bytes hurts. > > Even when you decrapify it and can reuse i_lock or something, > > then it is still 16 bytes on 64-bit. > > We can get it even smaller if we make it an hlist. A hlist_head is > only a single pointer. This size growth appears to be one of the > biggest weakness of the code. 8 bytes would be a lot better than 24. > > I haven't looked through all the patches... but this is to > > speed up a slowpath operation, isn't it? Or does revoke > > need to be especially performant? > > This was more about simplicity rather than performance. The > performance gain is using a per inode lock instead of a global lock. > Which keeps cache lines from bouncing. Yes but we already have such a global lock which has been OK until now. Granted that some users are running into these locks, but fine graining them can be considered independently I think. So using per-sb lists of files and not bloating struct inode any more could be a less controversial step for you. > > So this patch is purely a perofrmance improvement? Then I think > > it needs to be justified with numbers and the downsides (bloating > > struct inode in particulra) to be changelogged. > > Certainly the cost. > > One of the things I have discovered since I wrote this patch is the > i_devices list. Which means we don't necessarily need to have heads > in places other than struct inode. A character device driver (aka the > tty code) can walk it's inode list and from each inode walk the file > list. I need to check the locking on that one. > > If that simplification works we can move all maintenance of the file > list into the vfs and not need a separate file list concept. I will > take a look. Thanks, Nick -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2009-06-09 10:41 UTC|newest] Thread overview: 207+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-04-11 12:01 [RFC][PATCH 0/9] File descriptor hot-unplug support Eric W. Biederman 2009-04-11 12:01 ` Eric W. Biederman 2009-04-11 12:03 ` [RFC][PATCH 1/9] mm: Introduce remap_file_mappings Eric W. Biederman 2009-04-11 12:03 ` Eric W. Biederman 2009-04-11 12:05 ` [RFC][PATCH 2/9] mm: Implement generic support for revoking a mapping Eric W. Biederman 2009-04-11 12:05 ` Eric W. Biederman 2009-04-11 12:05 ` Eric W. Biederman 2009-04-11 12:06 ` [RFC][PATCH 3/9] sysfs: Use remap_file_mappings Eric W. Biederman 2009-04-11 12:06 ` Eric W. Biederman 2009-04-11 12:06 ` Eric W. Biederman 2009-04-11 12:07 ` [RFC][PATCH 4/9] vfs: Generalize the file_list Eric W. Biederman 2009-04-11 12:07 ` Eric W. Biederman 2009-04-11 12:07 ` Eric W. Biederman 2009-04-11 12:08 ` [RFC][PATCH 5/9] vfs: Introduce basic infrastructure for revoking a file Eric W. Biederman 2009-04-11 12:08 ` Eric W. Biederman 2009-04-11 12:08 ` Eric W. Biederman 2009-04-14 22:12 ` Jonathan Corbet 2009-04-14 22:12 ` Jonathan Corbet 2009-04-15 2:55 ` Eric W. Biederman 2009-04-15 2:55 ` Eric W. Biederman 2009-04-15 2:55 ` Eric W. Biederman 2009-04-11 12:10 ` [RFC][PATCH 6/9] vfs: Utilize fops_read_lock where appropriate Eric W. Biederman 2009-04-11 12:10 ` Eric W. Biederman 2009-04-11 12:10 ` Eric W. Biederman 2009-04-11 12:11 ` [RFC][PATCH 7/9] vfs: Optimize fops_read_lock Eric W. Biederman 2009-04-11 12:11 ` Eric W. Biederman 2009-04-11 12:11 ` Eric W. Biederman 2009-04-11 12:13 ` [RFC][PATCH 8/9] vfs: Implement generic revoked file operations Eric W. Biederman 2009-04-11 12:13 ` Eric W. Biederman 2009-04-11 12:13 ` Eric W. Biederman 2009-04-12 18:56 ` Jamie Lokier 2009-04-12 18:56 ` Jamie Lokier 2009-04-12 20:04 ` Eric W. Biederman 2009-04-12 20:04 ` Eric W. Biederman 2009-04-12 20:31 ` Jamie Lokier 2009-04-12 20:31 ` Jamie Lokier 2009-04-12 21:53 ` Eric W. Biederman 2009-04-12 21:53 ` Eric W. Biederman 2009-04-12 20:54 ` Eric W. Biederman 2009-04-12 20:54 ` Eric W. Biederman 2009-04-12 21:02 ` Jamie Lokier 2009-04-12 21:02 ` Jamie Lokier 2009-04-12 23:06 ` Eric W. Biederman 2009-04-12 23:06 ` Eric W. Biederman 2009-04-11 12:14 ` [RFC][PATCH 9/9] proc: Use the generic vfs revoke facility that now exists Eric W. Biederman 2009-04-11 12:14 ` Eric W. Biederman 2009-04-11 15:58 ` [RFC][PATCH 0/9] File descriptor hot-unplug support Al Viro 2009-04-11 15:58 ` Al Viro 2009-04-11 16:49 ` Eric W. Biederman 2009-04-11 16:49 ` Eric W. Biederman 2009-04-11 16:56 ` Al Viro 2009-04-11 16:56 ` Al Viro 2009-04-11 23:57 ` Eric W. Biederman 2009-04-11 23:57 ` Eric W. Biederman 2009-04-12 20:21 ` Eric W. Biederman 2009-04-12 20:21 ` Eric W. Biederman 2009-04-14 3:16 ` Tejun Heo 2009-04-14 3:16 ` Tejun Heo 2009-04-14 7:39 ` Eric W. Biederman 2009-04-14 7:39 ` Eric W. Biederman 2009-04-14 7:45 ` Tejun Heo 2009-04-14 7:45 ` Tejun Heo 2009-04-14 8:27 ` Eric W. Biederman 2009-04-14 8:27 ` Eric W. Biederman 2009-04-14 8:49 ` Tejun Heo 2009-04-14 8:49 ` Tejun Heo 2009-04-14 15:07 ` Jamie Lokier 2009-04-14 15:07 ` Jamie Lokier 2009-04-14 19:09 ` Eric W. Biederman 2009-04-14 19:09 ` Eric W. Biederman 2009-06-01 21:45 ` [PATCH 0/23] File descriptor hot-unplug support v2 Eric W. Biederman 2009-06-01 21:45 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 01/23] mm: Introduce revoke_file_mappings Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 22:25 ` Andrew Morton 2009-06-01 22:25 ` Andrew Morton 2009-06-02 0:12 ` Eric W. Biederman 2009-06-02 0:12 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 02/23] vfs: Implement unpoll_file Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-06 8:08 ` Al Viro 2009-06-06 8:08 ` Al Viro 2009-06-01 21:50 ` [PATCH 03/23] vfs: Generalize the file_list Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-02 7:06 ` Nick Piggin 2009-06-02 7:06 ` Nick Piggin 2009-06-05 19:33 ` Eric W. Biederman 2009-06-05 19:33 ` Eric W. Biederman 2009-06-09 10:38 ` Nick Piggin [this message] 2009-06-09 10:38 ` Nick Piggin 2009-06-09 18:38 ` Eric W. Biederman 2009-06-09 18:38 ` Eric W. Biederman 2009-06-10 6:05 ` Nick Piggin 2009-06-10 6:05 ` Nick Piggin 2009-06-01 21:50 ` [PATCH 04/23] vfs: Introduce infrastructure for revoking a file Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-02 5:16 ` Pekka Enberg 2009-06-02 5:16 ` Pekka Enberg 2009-06-02 6:51 ` Eric W. Biederman 2009-06-02 6:51 ` Eric W. Biederman 2009-06-02 7:08 ` Pekka Enberg 2009-06-02 7:08 ` Pekka Enberg 2009-06-02 7:08 ` Pekka Enberg 2009-06-02 7:14 ` Nick Piggin 2009-06-02 7:14 ` Nick Piggin 2009-06-02 17:06 ` Linus Torvalds 2009-06-02 17:06 ` Linus Torvalds 2009-06-02 20:52 ` Eric W. Biederman 2009-06-02 20:52 ` Eric W. Biederman 2009-06-03 6:37 ` Nick Piggin 2009-06-03 6:37 ` Nick Piggin 2009-06-02 22:56 ` Eric W. Biederman 2009-06-02 22:56 ` Eric W. Biederman 2009-06-03 6:38 ` Nick Piggin 2009-06-03 6:38 ` Nick Piggin 2009-06-05 9:03 ` Miklos Szeredi 2009-06-05 9:03 ` Miklos Szeredi 2009-06-05 19:06 ` Eric W. Biederman 2009-06-05 19:06 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 05/23] vfs: Teach lseek to use file_hotplug_lock Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 06/23] vfs: Teach read/write to use file_hotplug_read_lock Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 07/23] vfs: Teach sendfile,splice,tee,and vmsplice to use file_hotplug_lock Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-03 23:39 ` Badari Pulavarty 2009-06-03 23:39 ` Badari Pulavarty 2009-06-05 19:37 ` Eric W. Biederman 2009-06-05 19:37 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 08/23] vfs: Teach readdir " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 09/23] vfs: Teach poll and select " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 10/23] vfs: Teach do_path_lookup " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 11/23] mm: Teach mmap " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 12/23] vfs: Teach fcntl " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 13/23] vfs: Teach ioctl " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 14/23] vfs: Teach flock " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 15/23] vfs: Teach fallocate, and filp_close " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 16/23] vfs: Teach fstatfs, fstatfs64, ftruncate, fchdir, fchmod, fchown " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 17/23] proc: Teach /proc/<pid>/fd " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 18/23] vfs: Teach epoll " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-02 16:51 ` Davide Libenzi 2009-06-02 16:51 ` Davide Libenzi 2009-06-02 21:23 ` Eric W. Biederman 2009-06-02 21:23 ` Eric W. Biederman 2009-06-02 21:52 ` Davide Libenzi 2009-06-02 21:52 ` Davide Libenzi 2009-06-02 22:51 ` Eric W. Biederman 2009-06-02 22:51 ` Eric W. Biederman 2009-06-03 14:57 ` Davide Libenzi 2009-06-03 14:57 ` Davide Libenzi 2009-06-03 20:53 ` Eric W. Biederman 2009-06-03 20:53 ` Eric W. Biederman 2009-06-04 0:50 ` Davide Libenzi 2009-06-04 0:50 ` Davide Libenzi 2009-06-04 1:42 ` Eric W. Biederman 2009-06-04 1:42 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 19/23] eventpoll: Fix comment Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 20/23] vfs: Teach aio to use file_hotplug_lock Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 21/23] vfs: Teach fsync " Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 22/23] vfs: Teach fadvice to file_hotplug_lock Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-01 21:50 ` [PATCH 23/23] vfs: Teach readahead to use the file_hotplug_lock Eric W. Biederman 2009-06-01 21:50 ` Eric W. Biederman 2009-06-03 23:25 ` Badari Pulavarty 2009-06-03 23:25 ` Badari Pulavarty 2009-06-06 8:03 ` [PATCH 0/23] File descriptor hot-unplug support v2 Al Viro 2009-06-06 8:03 ` Al Viro 2009-06-08 9:41 ` Miklos Szeredi 2009-06-08 9:41 ` Miklos Szeredi 2009-06-08 10:24 ` Jamie Lokier 2009-06-08 10:24 ` Jamie Lokier 2009-06-08 16:29 ` Al Viro 2009-06-08 16:29 ` Al Viro 2009-06-08 16:44 ` Miklos Szeredi 2009-06-08 16:44 ` Miklos Szeredi 2009-06-08 17:50 ` Al Viro 2009-06-08 17:50 ` Al Viro 2009-06-08 18:01 ` Linus Torvalds 2009-06-08 18:01 ` Linus Torvalds 2009-06-08 18:50 ` Al Viro 2009-06-08 18:50 ` Al Viro 2009-06-08 19:18 ` Linus Torvalds 2009-06-08 19:18 ` Linus Torvalds 2009-06-09 6:42 ` Eric W. Biederman 2009-06-09 6:42 ` Eric W. Biederman 2009-06-09 10:52 ` Nick Piggin 2009-06-09 10:52 ` Nick Piggin 2009-06-09 5:50 ` Miklos Szeredi 2009-06-09 5:50 ` Miklos Szeredi 2009-06-09 6:31 ` Eric W. Biederman 2009-06-09 6:31 ` Eric W. Biederman 2009-06-09 6:22 ` Eric W. Biederman 2009-06-09 6:22 ` Eric W. Biederman
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090609103832.GI14820@wotan.suse.de \ --to=npiggin@suse.de \ --cc=adobriyan@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=alan@lxorguk.ukuu.org.uk \ --cc=ebiederm@aristanetworks.com \ --cc=ebiederm@xmission.com \ --cc=gregkh@suse.de \ --cc=hch@infradead.org \ --cc=hugh@veritas.com \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-pci@vger.kernel.org \ --cc=tj@kernel.org \ --cc=torvalds@linux-foundation.org \ --cc=viro@ZenIV.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.