Re: [PATCH v2 1/5] add metadata_incore ioctl in vfs
From: Arnd Bergmann <hidden>
Date: 2011-01-05 09:42:36
Also in:
linux-fsdevel
On Wednesday 05 January 2011 03:17:16 Shaohua Li wrote:
On Tue, 2011-01-04 at 17:40 +0800, Arnd Bergmann wrote:quoted
Have you tried passing just a single metadata_incore_ent at the ioctl and looping in user space? I would guess the extra overhead of that would be small enough, but that might need to be measured.metadata usually isn't continuous, so this means we have a lot of metadata_incore_ent entries. And this is called at boot time and I want to make the overhead as low as possible to not impact boot. Unless there are certain reasons we can't use indirect pointers, I'd like to make kernel return a vector of entries.
It's not a strict rule, but the indirect data passing is rather ugly and I'd only do that if the difference can be /measured/. If the purpose is to speed up boot time by preloading metadata, the FIMETADATA_INCORE operations should of course not take a significant amount of time compared to the actual preloading, but as long as it's less than one percent of the time you need for the preload, I would just use the simpler interface.
quoted hunk ↗ jump to hunk
@@ -882,6 +882,7 @@ COMPATIBLE_IOCTL(FIGETBSZ) /* 'X' - originally XFS but some now in the VFS */ COMPATIBLE_IOCTL(FIFREEZE) COMPATIBLE_IOCTL(FITHAW) +COMPATIBLE_IOCTL(FIMETADATA_INCORE) COMPATIBLE_IOCTL(KDGETKEYCODE) COMPATIBLE_IOCTL(KDSETKEYCODE) COMPATIBLE_IOCTL(KDGKBTYPE)
This change can go away as well. Two more general comments: - You probably want to add the ioctls to file_ioctl instead of do_vfs_ioctl, so you don't add another case statement to the common path. - I don't know if there are any rules for what should be an ioctl or an fcntl, we're rather inconsistent about this. If you have found a good reason for making it an ioctl, just put that into the changelog so we can refer to it next time. Arnd