2005-04-17 06:20:36 +08:00
|
|
|
The text below describes the locking rules for VFS-related methods.
|
|
|
|
|
It is (believed to be) up-to-date. *Please*, if you change anything in
|
|
|
|
|
prototypes or locking protocols - update this file. And update the relevant
|
|
|
|
|
instances in the tree, don't leave that to maintainers of filesystems/devices/
|
|
|
|
|
etc. At the very least, put the list of dubious cases in the end of this file.
|
|
|
|
|
Don't turn it into log - maintainers of out-of-the-tree code are supposed to
|
|
|
|
|
be able to use diff(1).
|
|
|
|
|
Thing currently missing here: socket operations. Alexey?
|
|
|
|
|
|
|
|
|
|
--------------------------- dentry_operations --------------------------
|
|
|
|
|
prototypes:
|
2012-06-11 04:03:43 +08:00
|
|
|
int (*d_revalidate)(struct dentry *, unsigned int);
|
2013-02-21 00:19:05 +08:00
|
|
|
int (*d_weak_revalidate)(struct dentry *, unsigned int);
|
2013-05-22 06:22:44 +08:00
|
|
|
int (*d_hash)(const struct dentry *, struct qstr *);
|
2016-08-01 04:37:25 +08:00
|
|
|
int (*d_compare)(const struct dentry *,
|
2011-01-07 14:49:27 +08:00
|
|
|
unsigned int, const char *, const struct qstr *);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*d_delete)(struct dentry *);
|
2016-06-28 17:47:32 +08:00
|
|
|
int (*d_init)(struct dentry *);
|
2005-04-17 06:20:36 +08:00
|
|
|
void (*d_release)(struct dentry *);
|
|
|
|
|
void (*d_iput)(struct dentry *, struct inode *);
|
2007-05-08 15:26:18 +08:00
|
|
|
char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
|
Add a dentry op to handle automounting rather than abusing follow_link()
Add a dentry op (d_automount) to handle automounting directories rather than
abusing the follow_link() inode operation. The operation is keyed off a new
dentry flag (DCACHE_NEED_AUTOMOUNT).
This also makes it easier to add an AT_ flag to suppress terminal segment
automount during pathwalk and removes the need for the kludge code in the
pathwalk algorithm to handle directories with follow_link() semantics.
The ->d_automount() dentry operation:
struct vfsmount *(*d_automount)(struct path *mountpoint);
takes a pointer to the directory to be mounted upon, which is expected to
provide sufficient data to determine what should be mounted. If successful, it
should return the vfsmount struct it creates (which it should also have added
to the namespace using do_add_mount() or similar). If there's a collision with
another automount attempt, NULL should be returned. If the directory specified
by the parameter should be used directly rather than being mounted upon,
-EISDIR should be returned. In any other case, an error code should be
returned.
The ->d_automount() operation is called with no locks held and may sleep. At
this point the pathwalk algorithm will be in ref-walk mode.
Within fs/namei.c itself, a new pathwalk subroutine (follow_automount()) is
added to handle mountpoints. It will return -EREMOTE if the automount flag was
set, but no d_automount() op was supplied, -ELOOP if we've encountered too many
symlinks or mountpoints, -EISDIR if the walk point should be used without
mounting and 0 if successful. The path will be updated to point to the mounted
filesystem if a successful automount took place.
__follow_mount() is replaced by follow_managed() which is more generic
(especially with the patch that adds ->d_manage()). This handles transits from
directories during pathwalk, including automounting and skipping over
mountpoints (and holding processes with the next patch).
__follow_mount_rcu() will jump out of RCU-walk mode if it encounters an
automount point with nothing mounted on it.
follow_dotdot*() does not handle automounts as you don't want to trigger them
whilst following "..".
I've also extracted the mount/don't-mount logic from autofs4 and included it
here. It makes the mount go ahead anyway if someone calls open() or creat(),
tries to traverse the directory, tries to chdir/chroot/etc. into the directory,
or sticks a '/' on the end of the pathname. If they do a stat(), however,
they'll only trigger the automount if they didn't also say O_NOFOLLOW.
I've also added an inode flag (S_AUTOMOUNT) so that filesystems can mark their
inodes as automount points. This flag is automatically propagated to the
dentry as DCACHE_NEED_AUTOMOUNT by __d_instantiate(). This saves NFS and could
save AFS a private flag bit apiece, but is not strictly necessary. It would be
preferable to do the propagation in d_set_d_op(), but that doesn't normally
have access to the inode.
[AV: fixed breakage in case if __follow_mount_rcu() fails and nameidata_drop_rcu()
succeeds in RCU case of do_lookup(); we need to fall through to non-RCU case after
that, rather than just returning with ungrabbed *path]
Signed-off-by: David Howells <dhowells@redhat.com>
Was-Acked-by: Ian Kent <raven@themaw.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-01-15 02:45:21 +08:00
|
|
|
struct vfsmount *(*d_automount)(struct path *path);
|
2016-11-24 05:03:41 +08:00
|
|
|
int (*d_manage)(const struct path *, bool);
|
2016-06-30 14:53:27 +08:00
|
|
|
struct dentry *(*d_real)(struct dentry *, const struct inode *,
|
|
|
|
|
unsigned int);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
locking rules:
|
2011-01-07 14:49:57 +08:00
|
|
|
rename_lock ->d_lock may block rcu-walk
|
|
|
|
|
d_revalidate: no no yes (ref-walk) maybe
|
2013-02-21 00:19:05 +08:00
|
|
|
d_weak_revalidate:no no yes no
|
2011-01-07 14:49:57 +08:00
|
|
|
d_hash no no no maybe
|
|
|
|
|
d_compare: yes no no maybe
|
|
|
|
|
d_delete: no yes no no
|
2016-06-28 17:47:32 +08:00
|
|
|
d_init: no no yes no
|
2011-01-07 14:49:57 +08:00
|
|
|
d_release: no no yes no
|
2011-10-29 01:02:42 +08:00
|
|
|
d_prune: no yes no no
|
2011-01-07 14:49:57 +08:00
|
|
|
d_iput: no no yes no
|
|
|
|
|
d_dname: no no no no
|
Add a dentry op to handle automounting rather than abusing follow_link()
Add a dentry op (d_automount) to handle automounting directories rather than
abusing the follow_link() inode operation. The operation is keyed off a new
dentry flag (DCACHE_NEED_AUTOMOUNT).
This also makes it easier to add an AT_ flag to suppress terminal segment
automount during pathwalk and removes the need for the kludge code in the
pathwalk algorithm to handle directories with follow_link() semantics.
The ->d_automount() dentry operation:
struct vfsmount *(*d_automount)(struct path *mountpoint);
takes a pointer to the directory to be mounted upon, which is expected to
provide sufficient data to determine what should be mounted. If successful, it
should return the vfsmount struct it creates (which it should also have added
to the namespace using do_add_mount() or similar). If there's a collision with
another automount attempt, NULL should be returned. If the directory specified
by the parameter should be used directly rather than being mounted upon,
-EISDIR should be returned. In any other case, an error code should be
returned.
The ->d_automount() operation is called with no locks held and may sleep. At
this point the pathwalk algorithm will be in ref-walk mode.
Within fs/namei.c itself, a new pathwalk subroutine (follow_automount()) is
added to handle mountpoints. It will return -EREMOTE if the automount flag was
set, but no d_automount() op was supplied, -ELOOP if we've encountered too many
symlinks or mountpoints, -EISDIR if the walk point should be used without
mounting and 0 if successful. The path will be updated to point to the mounted
filesystem if a successful automount took place.
__follow_mount() is replaced by follow_managed() which is more generic
(especially with the patch that adds ->d_manage()). This handles transits from
directories during pathwalk, including automounting and skipping over
mountpoints (and holding processes with the next patch).
__follow_mount_rcu() will jump out of RCU-walk mode if it encounters an
automount point with nothing mounted on it.
follow_dotdot*() does not handle automounts as you don't want to trigger them
whilst following "..".
I've also extracted the mount/don't-mount logic from autofs4 and included it
here. It makes the mount go ahead anyway if someone calls open() or creat(),
tries to traverse the directory, tries to chdir/chroot/etc. into the directory,
or sticks a '/' on the end of the pathname. If they do a stat(), however,
they'll only trigger the automount if they didn't also say O_NOFOLLOW.
I've also added an inode flag (S_AUTOMOUNT) so that filesystems can mark their
inodes as automount points. This flag is automatically propagated to the
dentry as DCACHE_NEED_AUTOMOUNT by __d_instantiate(). This saves NFS and could
save AFS a private flag bit apiece, but is not strictly necessary. It would be
preferable to do the propagation in d_set_d_op(), but that doesn't normally
have access to the inode.
[AV: fixed breakage in case if __follow_mount_rcu() fails and nameidata_drop_rcu()
succeeds in RCU case of do_lookup(); we need to fall through to non-RCU case after
that, rather than just returning with ungrabbed *path]
Signed-off-by: David Howells <dhowells@redhat.com>
Was-Acked-by: Ian Kent <raven@themaw.net>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2011-01-15 02:45:21 +08:00
|
|
|
d_automount: no no yes no
|
2011-01-15 02:46:51 +08:00
|
|
|
d_manage: no no yes (ref-walk) maybe
|
2016-06-30 14:53:27 +08:00
|
|
|
d_real no no yes no
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
--------------------------- inode_operations ---------------------------
|
|
|
|
|
prototypes:
|
2012-06-11 06:05:36 +08:00
|
|
|
int (*create) (struct inode *,struct dentry *,umode_t, bool);
|
2012-06-11 05:13:09 +08:00
|
|
|
struct dentry * (*lookup) (struct inode *,struct dentry *, unsigned int);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*link) (struct dentry *,struct inode *,struct dentry *);
|
|
|
|
|
int (*unlink) (struct inode *,struct dentry *);
|
|
|
|
|
int (*symlink) (struct inode *,struct dentry *,const char *);
|
2011-07-26 13:41:39 +08:00
|
|
|
int (*mkdir) (struct inode *,struct dentry *,umode_t);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*rmdir) (struct inode *,struct dentry *);
|
2011-07-26 13:52:52 +08:00
|
|
|
int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*rename) (struct inode *, struct dentry *,
|
2014-04-01 23:08:42 +08:00
|
|
|
struct inode *, struct dentry *, unsigned int);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*readlink) (struct dentry *, char __user *,int);
|
2015-11-17 23:20:54 +08:00
|
|
|
const char *(*get_link) (struct dentry *, struct inode *, void **);
|
2005-04-17 06:20:36 +08:00
|
|
|
void (*truncate) (struct inode *);
|
2011-01-07 14:49:58 +08:00
|
|
|
int (*permission) (struct inode *, int, unsigned int);
|
2011-07-23 23:37:31 +08:00
|
|
|
int (*get_acl)(struct inode *, int);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*setattr) (struct dentry *, struct iattr *);
|
statx: Add a system call to make enhanced file info available
Add a system call to make extended file information available, including
file creation and some attribute flags where available through the
underlying filesystem.
The getattr inode operation is altered to take two additional arguments: a
u32 request_mask and an unsigned int flags that indicate the
synchronisation mode. This change is propagated to the vfs_getattr*()
function.
Functions like vfs_stat() are now inline wrappers around new functions
vfs_statx() and vfs_statx_fd() to reduce stack usage.
========
OVERVIEW
========
The idea was initially proposed as a set of xattrs that could be retrieved
with getxattr(), but the general preference proved to be for a new syscall
with an extended stat structure.
A number of requests were gathered for features to be included. The
following have been included:
(1) Make the fields a consistent size on all arches and make them large.
(2) Spare space, request flags and information flags are provided for
future expansion.
(3) Better support for the y2038 problem [Arnd Bergmann] (tv_sec is an
__s64).
(4) Creation time: The SMB protocol carries the creation time, which could
be exported by Samba, which will in turn help CIFS make use of
FS-Cache as that can be used for coherency data (stx_btime).
This is also specified in NFSv4 as a recommended attribute and could
be exported by NFSD [Steve French].
(5) Lightweight stat: Ask for just those details of interest, and allow a
netfs (such as NFS) to approximate anything not of interest, possibly
without going to the server [Trond Myklebust, Ulrich Drepper, Andreas
Dilger] (AT_STATX_DONT_SYNC).
(6) Heavyweight stat: Force a netfs to go to the server, even if it thinks
its cached attributes are up to date [Trond Myklebust]
(AT_STATX_FORCE_SYNC).
And the following have been left out for future extension:
(7) Data version number: Could be used by userspace NFS servers [Aneesh
Kumar].
Can also be used to modify fill_post_wcc() in NFSD which retrieves
i_version directly, but has just called vfs_getattr(). It could get
it from the kstat struct if it used vfs_xgetattr() instead.
(There's disagreement on the exact semantics of a single field, since
not all filesystems do this the same way).
(8) BSD stat compatibility: Including more fields from the BSD stat such
as creation time (st_btime) and inode generation number (st_gen)
[Jeremy Allison, Bernd Schubert].
(9) Inode generation number: Useful for FUSE and userspace NFS servers
[Bernd Schubert].
(This was asked for but later deemed unnecessary with the
open-by-handle capability available and caused disagreement as to
whether it's a security hole or not).
(10) Extra coherency data may be useful in making backups [Andreas Dilger].
(No particular data were offered, but things like last backup
timestamp, the data version number and the DOS archive bit would come
into this category).
(11) Allow the filesystem to indicate what it can/cannot provide: A
filesystem can now say it doesn't support a standard stat feature if
that isn't available, so if, for instance, inode numbers or UIDs don't
exist or are fabricated locally...
(This requires a separate system call - I have an fsinfo() call idea
for this).
(12) Store a 16-byte volume ID in the superblock that can be returned in
struct xstat [Steve French].
(Deferred to fsinfo).
(13) Include granularity fields in the time data to indicate the
granularity of each of the times (NFSv4 time_delta) [Steve French].
(Deferred to fsinfo).
(14) FS_IOC_GETFLAGS value. These could be translated to BSD's st_flags.
Note that the Linux IOC flags are a mess and filesystems such as Ext4
define flags that aren't in linux/fs.h, so translation in the kernel
may be a necessity (or, possibly, we provide the filesystem type too).
(Some attributes are made available in stx_attributes, but the general
feeling was that the IOC flags were to ext[234]-specific and shouldn't
be exposed through statx this way).
(15) Mask of features available on file (eg: ACLs, seclabel) [Brad Boyer,
Michael Kerrisk].
(Deferred, probably to fsinfo. Finding out if there's an ACL or
seclabal might require extra filesystem operations).
(16) Femtosecond-resolution timestamps [Dave Chinner].
(A __reserved field has been left in the statx_timestamp struct for
this - if there proves to be a need).
(17) A set multiple attributes syscall to go with this.
===============
NEW SYSTEM CALL
===============
The new system call is:
int ret = statx(int dfd,
const char *filename,
unsigned int flags,
unsigned int mask,
struct statx *buffer);
The dfd, filename and flags parameters indicate the file to query, in a
similar way to fstatat(). There is no equivalent of lstat() as that can be
emulated with statx() by passing AT_SYMLINK_NOFOLLOW in flags. There is
also no equivalent of fstat() as that can be emulated by passing a NULL
filename to statx() with the fd of interest in dfd.
Whether or not statx() synchronises the attributes with the backing store
can be controlled by OR'ing a value into the flags argument (this typically
only affects network filesystems):
(1) AT_STATX_SYNC_AS_STAT tells statx() to behave as stat() does in this
respect.
(2) AT_STATX_FORCE_SYNC will require a network filesystem to synchronise
its attributes with the server - which might require data writeback to
occur to get the timestamps correct.
(3) AT_STATX_DONT_SYNC will suppress synchronisation with the server in a
network filesystem. The resulting values should be considered
approximate.
mask is a bitmask indicating the fields in struct statx that are of
interest to the caller. The user should set this to STATX_BASIC_STATS to
get the basic set returned by stat(). It should be noted that asking for
more information may entail extra I/O operations.
buffer points to the destination for the data. This must be 256 bytes in
size.
======================
MAIN ATTRIBUTES RECORD
======================
The following structures are defined in which to return the main attribute
set:
struct statx_timestamp {
__s64 tv_sec;
__s32 tv_nsec;
__s32 __reserved;
};
struct statx {
__u32 stx_mask;
__u32 stx_blksize;
__u64 stx_attributes;
__u32 stx_nlink;
__u32 stx_uid;
__u32 stx_gid;
__u16 stx_mode;
__u16 __spare0[1];
__u64 stx_ino;
__u64 stx_size;
__u64 stx_blocks;
__u64 __spare1[1];
struct statx_timestamp stx_atime;
struct statx_timestamp stx_btime;
struct statx_timestamp stx_ctime;
struct statx_timestamp stx_mtime;
__u32 stx_rdev_major;
__u32 stx_rdev_minor;
__u32 stx_dev_major;
__u32 stx_dev_minor;
__u64 __spare2[14];
};
The defined bits in request_mask and stx_mask are:
STATX_TYPE Want/got stx_mode & S_IFMT
STATX_MODE Want/got stx_mode & ~S_IFMT
STATX_NLINK Want/got stx_nlink
STATX_UID Want/got stx_uid
STATX_GID Want/got stx_gid
STATX_ATIME Want/got stx_atime{,_ns}
STATX_MTIME Want/got stx_mtime{,_ns}
STATX_CTIME Want/got stx_ctime{,_ns}
STATX_INO Want/got stx_ino
STATX_SIZE Want/got stx_size
STATX_BLOCKS Want/got stx_blocks
STATX_BASIC_STATS [The stuff in the normal stat struct]
STATX_BTIME Want/got stx_btime{,_ns}
STATX_ALL [All currently available stuff]
stx_btime is the file creation time, stx_mask is a bitmask indicating the
data provided and __spares*[] are where as-yet undefined fields can be
placed.
Time fields are structures with separate seconds and nanoseconds fields
plus a reserved field in case we want to add even finer resolution. Note
that times will be negative if before 1970; in such a case, the nanosecond
fields will also be negative if not zero.
The bits defined in the stx_attributes field convey information about a
file, how it is accessed, where it is and what it does. The following
attributes map to FS_*_FL flags and are the same numerical value:
STATX_ATTR_COMPRESSED File is compressed by the fs
STATX_ATTR_IMMUTABLE File is marked immutable
STATX_ATTR_APPEND File is append-only
STATX_ATTR_NODUMP File is not to be dumped
STATX_ATTR_ENCRYPTED File requires key to decrypt in fs
Within the kernel, the supported flags are listed by:
KSTAT_ATTR_FS_IOC_FLAGS
[Are any other IOC flags of sufficient general interest to be exposed
through this interface?]
New flags include:
STATX_ATTR_AUTOMOUNT Object is an automount trigger
These are for the use of GUI tools that might want to mark files specially,
depending on what they are.
Fields in struct statx come in a number of classes:
(0) stx_dev_*, stx_blksize.
These are local system information and are always available.
(1) stx_mode, stx_nlinks, stx_uid, stx_gid, stx_[amc]time, stx_ino,
stx_size, stx_blocks.
These will be returned whether the caller asks for them or not. The
corresponding bits in stx_mask will be set to indicate whether they
actually have valid values.
If the caller didn't ask for them, then they may be approximated. For
example, NFS won't waste any time updating them from the server,
unless as a byproduct of updating something requested.
If the values don't actually exist for the underlying object (such as
UID or GID on a DOS file), then the bit won't be set in the stx_mask,
even if the caller asked for the value. In such a case, the returned
value will be a fabrication.
Note that there are instances where the type might not be valid, for
instance Windows reparse points.
(2) stx_rdev_*.
This will be set only if stx_mode indicates we're looking at a
blockdev or a chardev, otherwise will be 0.
(3) stx_btime.
Similar to (1), except this will be set to 0 if it doesn't exist.
=======
TESTING
=======
The following test program can be used to test the statx system call:
samples/statx/test-statx.c
Just compile and run, passing it paths to the files you want to examine.
The file is built automatically if CONFIG_SAMPLES is enabled.
Here's some example output. Firstly, an NFS directory that crosses to
another FSID. Note that the AUTOMOUNT attribute is set because transiting
this directory will cause d_automount to be invoked by the VFS.
[root@andromeda ~]# /tmp/test-statx -A /warthog/data
statx(/warthog/data) = 0
results=7ff
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:26 Inode: 1703937 Links: 125
Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041
Access: 2016-11-24 09:02:12.219699527+0000
Modify: 2016-11-17 10:44:36.225653653+0000
Change: 2016-11-17 10:44:36.225653653+0000
Attributes: 0000000000001000 (-------- -------- -------- -------- -------- -------- ---m---- --------)
Secondly, the result of automounting on that directory.
[root@andromeda ~]# /tmp/test-statx /warthog/data
statx(/warthog/data) = 0
results=7ff
Size: 4096 Blocks: 8 IO Block: 1048576 directory
Device: 00:27 Inode: 2 Links: 125
Access: (3777/drwxrwxrwx) Uid: 0 Gid: 4041
Access: 2016-11-24 09:02:12.219699527+0000
Modify: 2016-11-17 10:44:36.225653653+0000
Change: 2016-11-17 10:44:36.225653653+0000
Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2017-02-01 00:46:22 +08:00
|
|
|
int (*getattr) (const struct path *, struct dentry *, struct kstat *,
|
|
|
|
|
u32, unsigned int);
|
2005-04-17 06:20:36 +08:00
|
|
|
ssize_t (*listxattr) (struct dentry *, char *, size_t);
|
2010-12-16 19:04:54 +08:00
|
|
|
int (*fiemap)(struct inode *, struct fiemap_extent_info *, u64 start, u64 len);
|
2012-03-26 21:59:21 +08:00
|
|
|
void (*update_time)(struct inode *, struct timespec *, int);
|
2012-06-22 16:39:14 +08:00
|
|
|
int (*atomic_open)(struct inode *, struct dentry *,
|
2012-06-22 16:40:19 +08:00
|
|
|
struct file *, unsigned open_flag,
|
2012-06-10 17:01:45 +08:00
|
|
|
umode_t create_mode, int *opened);
|
2013-07-03 20:19:23 +08:00
|
|
|
int (*tmpfile) (struct inode *, struct dentry *, umode_t);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
locking rules:
|
2010-12-16 19:04:54 +08:00
|
|
|
all may block
|
2007-05-09 13:53:16 +08:00
|
|
|
i_mutex(inode)
|
2005-04-17 06:20:36 +08:00
|
|
|
lookup: yes
|
|
|
|
|
create: yes
|
|
|
|
|
link: yes (both)
|
|
|
|
|
mknod: yes
|
|
|
|
|
symlink: yes
|
|
|
|
|
mkdir: yes
|
|
|
|
|
unlink: yes (both)
|
|
|
|
|
rmdir: yes (both) (see below)
|
2016-09-27 17:03:58 +08:00
|
|
|
rename: yes (all) (see below)
|
2005-04-17 06:20:36 +08:00
|
|
|
readlink: no
|
2015-11-17 23:20:54 +08:00
|
|
|
get_link: no
|
2005-04-17 06:20:36 +08:00
|
|
|
setattr: yes
|
2011-01-07 14:49:58 +08:00
|
|
|
permission: no (may not block if called in rcu-walk mode)
|
2011-07-23 23:37:31 +08:00
|
|
|
get_acl: no
|
2005-04-17 06:20:36 +08:00
|
|
|
getattr: no
|
|
|
|
|
listxattr: no
|
2010-12-16 19:04:54 +08:00
|
|
|
fiemap: no
|
2012-03-26 21:59:21 +08:00
|
|
|
update_time: no
|
2012-06-05 21:10:17 +08:00
|
|
|
atomic_open: yes
|
2013-07-03 20:19:23 +08:00
|
|
|
tmpfile: no
|
2012-03-26 21:59:21 +08:00
|
|
|
|
xattr: Stop calling {get,set,remove}xattr inode operations
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.
This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.
Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.
In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-09-29 23:48:44 +08:00
|
|
|
|
2007-05-09 13:53:16 +08:00
|
|
|
Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
|
2005-04-17 06:20:36 +08:00
|
|
|
victim.
|
2016-09-27 17:03:58 +08:00
|
|
|
cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
See Documentation/filesystems/directory-locking for more detailed discussion
|
|
|
|
|
of the locking scheme for directory operations.
|
|
|
|
|
|
xattr: Stop calling {get,set,remove}xattr inode operations
All filesystems that support xattrs by now do so via xattr handlers.
They all define sb->s_xattr, and their getxattr, setxattr, and
removexattr inode operations use the generic inode operations. On
filesystems that don't support xattrs, the xattr inode operations are
all NULL, and sb->s_xattr is also NULL.
This means that we can remove the getxattr, setxattr, and removexattr
inode operations and directly call the generic handlers, or better,
inline expand those handlers into fs/xattr.c.
Filesystems that do not support xattrs on some inodes should clear the
IOP_XATTR i_opflags flag in those inodes. (Right now, some filesystems
have checks to disable xattrs on some inodes in the ->list, ->get, and
->set xattr handler operations instead.) The IOP_XATTR flag is
automatically cleared in inodes of filesystems that don't have xattr
support.
In orangefs, symlinks do have a setxattr iop but no getxattr iop. Add a
check for symlinks to orangefs_inode_getxattr to preserve the current,
weird behavior; that check may not be necessary though.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-09-29 23:48:44 +08:00
|
|
|
----------------------- xattr_handler operations -----------------------
|
|
|
|
|
prototypes:
|
|
|
|
|
bool (*list)(struct dentry *dentry);
|
|
|
|
|
int (*get)(const struct xattr_handler *handler, struct dentry *dentry,
|
|
|
|
|
struct inode *inode, const char *name, void *buffer,
|
|
|
|
|
size_t size);
|
|
|
|
|
int (*set)(const struct xattr_handler *handler, struct dentry *dentry,
|
|
|
|
|
struct inode *inode, const char *name, const void *buffer,
|
|
|
|
|
size_t size, int flags);
|
|
|
|
|
|
|
|
|
|
locking rules:
|
|
|
|
|
all may block
|
|
|
|
|
i_mutex(inode)
|
|
|
|
|
list: no
|
|
|
|
|
get: no
|
|
|
|
|
set: yes
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
--------------------------- super_operations ---------------------------
|
|
|
|
|
prototypes:
|
|
|
|
|
struct inode *(*alloc_inode)(struct super_block *sb);
|
|
|
|
|
void (*destroy_inode)(struct inode *);
|
2011-05-27 18:53:02 +08:00
|
|
|
void (*dirty_inode) (struct inode *, int flags);
|
2010-12-16 19:04:54 +08:00
|
|
|
int (*write_inode) (struct inode *, struct writeback_control *wbc);
|
2010-06-08 12:37:12 +08:00
|
|
|
int (*drop_inode) (struct inode *);
|
|
|
|
|
void (*evict_inode) (struct inode *);
|
2005-04-17 06:20:36 +08:00
|
|
|
void (*put_super) (struct super_block *);
|
|
|
|
|
int (*sync_fs)(struct super_block *sb, int wait);
|
2009-01-10 08:40:58 +08:00
|
|
|
int (*freeze_fs) (struct super_block *);
|
|
|
|
|
int (*unfreeze_fs) (struct super_block *);
|
2006-06-23 17:02:58 +08:00
|
|
|
int (*statfs) (struct dentry *, struct kstatfs *);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*remount_fs) (struct super_block *, int *, char *);
|
|
|
|
|
void (*umount_begin) (struct super_block *);
|
2011-12-09 10:32:45 +08:00
|
|
|
int (*show_options)(struct seq_file *, struct dentry *);
|
2005-04-17 06:20:36 +08:00
|
|
|
ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t);
|
|
|
|
|
ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t);
|
2010-12-16 19:04:54 +08:00
|
|
|
int (*bdev_try_to_free_page)(struct super_block*, struct page*, gfp_t);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
locking rules:
|
2010-06-08 12:37:12 +08:00
|
|
|
All may block [not true, see below]
|
2009-06-20 02:22:37 +08:00
|
|
|
s_umount
|
|
|
|
|
alloc_inode:
|
|
|
|
|
destroy_inode:
|
2011-05-27 18:53:02 +08:00
|
|
|
dirty_inode:
|
2009-06-20 02:22:37 +08:00
|
|
|
write_inode:
|
2011-03-22 19:23:39 +08:00
|
|
|
drop_inode: !!!inode->i_lock!!!
|
2010-06-08 12:37:12 +08:00
|
|
|
evict_inode:
|
2009-06-20 02:22:37 +08:00
|
|
|
put_super: write
|
|
|
|
|
sync_fs: read
|
2012-06-12 22:20:48 +08:00
|
|
|
freeze_fs: write
|
|
|
|
|
unfreeze_fs: write
|
2010-06-08 12:37:12 +08:00
|
|
|
statfs: maybe(read) (see below)
|
|
|
|
|
remount_fs: write
|
2009-06-20 02:22:37 +08:00
|
|
|
umount_begin: no
|
|
|
|
|
show_options: no (namespace_sem)
|
|
|
|
|
quota_read: no (see below)
|
|
|
|
|
quota_write: no (see below)
|
2010-12-16 19:04:54 +08:00
|
|
|
bdev_try_to_free_page: no (see below)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-06-08 12:37:12 +08:00
|
|
|
->statfs() has s_umount (shared) when called by ustat(2) (native or
|
|
|
|
|
compat), but that's an accident of bad API; s_umount is used to pin
|
|
|
|
|
the superblock down when we only have dev_t given us by userland to
|
|
|
|
|
identify the superblock. Everything else (statfs(), fstatfs(), etc.)
|
|
|
|
|
doesn't hold it when calling ->statfs() - superblock is pinned down
|
|
|
|
|
by resolving the pathname passed to syscall.
|
2005-04-17 06:20:36 +08:00
|
|
|
->quota_read() and ->quota_write() functions are both guaranteed to
|
|
|
|
|
be the only ones operating on the quota file by the quota code (via
|
|
|
|
|
dqio_sem) (unless an admin really wants to screw up something and
|
|
|
|
|
writes to quota files with quotas on). For other details about locking
|
|
|
|
|
see also dquot_operations section.
|
2010-12-16 19:04:54 +08:00
|
|
|
->bdev_try_to_free_page is called from the ->releasepage handler of
|
|
|
|
|
the block device inode. See there for more details.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
--------------------------- file_system_type ---------------------------
|
|
|
|
|
prototypes:
|
2010-12-16 19:04:54 +08:00
|
|
|
struct dentry *(*mount) (struct file_system_type *, int,
|
|
|
|
|
const char *, void *);
|
2005-04-17 06:20:36 +08:00
|
|
|
void (*kill_sb) (struct super_block *);
|
|
|
|
|
locking rules:
|
2010-12-16 19:04:54 +08:00
|
|
|
may block
|
|
|
|
|
mount yes
|
|
|
|
|
kill_sb yes
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-03-16 21:07:58 +08:00
|
|
|
->mount() returns ERR_PTR or the root dentry; its superblock should be locked
|
|
|
|
|
on return.
|
2005-04-17 06:20:36 +08:00
|
|
|
->kill_sb() takes a write-locked superblock, does all shutdown work on it,
|
|
|
|
|
unlocks and drops the reference.
|
|
|
|
|
|
|
|
|
|
--------------------------- address_space_operations --------------------------
|
|
|
|
|
prototypes:
|
|
|
|
|
int (*writepage)(struct page *page, struct writeback_control *wbc);
|
|
|
|
|
int (*readpage)(struct file *, struct page *);
|
|
|
|
|
int (*writepages)(struct address_space *, struct writeback_control *);
|
|
|
|
|
int (*set_page_dirty)(struct page *page);
|
|
|
|
|
int (*readpages)(struct file *filp, struct address_space *mapping,
|
|
|
|
|
struct list_head *pages, unsigned nr_pages);
|
2008-10-30 05:00:55 +08:00
|
|
|
int (*write_begin)(struct file *, struct address_space *mapping,
|
|
|
|
|
loff_t pos, unsigned len, unsigned flags,
|
|
|
|
|
struct page **pagep, void **fsdata);
|
|
|
|
|
int (*write_end)(struct file *, struct address_space *mapping,
|
|
|
|
|
loff_t pos, unsigned len, unsigned copied,
|
|
|
|
|
struct page *page, void *fsdata);
|
2005-04-17 06:20:36 +08:00
|
|
|
sector_t (*bmap)(struct address_space *, sector_t);
|
2013-05-22 11:17:23 +08:00
|
|
|
void (*invalidatepage) (struct page *, unsigned int, unsigned int);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*releasepage) (struct page *, int);
|
2010-12-02 02:35:19 +08:00
|
|
|
void (*freepage)(struct page *);
|
2016-04-07 23:51:58 +08:00
|
|
|
int (*direct_IO)(struct kiocb *, struct iov_iter *iter);
|
mm: migrate: support non-lru movable page migration
We have allowed migration for only LRU pages until now and it was enough
to make high-order pages. But recently, embedded system(e.g., webOS,
android) uses lots of non-movable pages(e.g., zram, GPU memory) so we
have seen several reports about troubles of small high-order allocation.
For fixing the problem, there were several efforts (e,g,. enhance
compaction algorithm, SLUB fallback to 0-order page, reserved memory,
vmalloc and so on) but if there are lots of non-movable pages in system,
their solutions are void in the long run.
So, this patch is to support facility to change non-movable pages with
movable. For the feature, this patch introduces functions related to
migration to address_space_operations as well as some page flags.
If a driver want to make own pages movable, it should define three
functions which are function pointers of struct
address_space_operations.
1. bool (*isolate_page) (struct page *page, isolate_mode_t mode);
What VM expects on isolate_page function of driver is to return *true*
if driver isolates page successfully. On returing true, VM marks the
page as PG_isolated so concurrent isolation in several CPUs skip the
page for isolation. If a driver cannot isolate the page, it should
return *false*.
Once page is successfully isolated, VM uses page.lru fields so driver
shouldn't expect to preserve values in that fields.
2. int (*migratepage) (struct address_space *mapping,
struct page *newpage, struct page *oldpage, enum migrate_mode);
After isolation, VM calls migratepage of driver with isolated page. The
function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
indicate to the VM the oldpage is no longer movable via
__ClearPageMovable() under page_lock if you migrated the oldpage
successfully and returns 0. If driver cannot migrate the page at the
moment, driver can return -EAGAIN. On -EAGAIN, VM will retry page
migration in a short time because VM interprets -EAGAIN as "temporal
migration failure". On returning any error except -EAGAIN, VM will give
up the page migration without retrying in this time.
Driver shouldn't touch page.lru field VM using in the functions.
3. void (*putback_page)(struct page *);
If migration fails on isolated page, VM should return the isolated page
to the driver so VM calls driver's putback_page with migration failed
page. In this function, driver should put the isolated page back to the
own data structure.
4. non-lru movable page flags
There are two page flags for supporting non-lru movable page.
* PG_movable
Driver should use the below function to make page movable under
page_lock.
void __SetPageMovable(struct page *page, struct address_space *mapping)
It needs argument of address_space for registering migration family
functions which will be called by VM. Exactly speaking, PG_movable is
not a real flag of struct page. Rather than, VM reuses page->mapping's
lower bits to represent it.
#define PAGE_MAPPING_MOVABLE 0x2
page->mapping = page->mapping | PAGE_MAPPING_MOVABLE;
so driver shouldn't access page->mapping directly. Instead, driver
should use page_mapping which mask off the low two bits of page->mapping
so it can get right struct address_space.
For testing of non-lru movable page, VM supports __PageMovable function.
However, it doesn't guarantee to identify non-lru movable page because
page->mapping field is unified with other variables in struct page. As
well, if driver releases the page after isolation by VM, page->mapping
doesn't have stable value although it has PAGE_MAPPING_MOVABLE (Look at
__ClearPageMovable). But __PageMovable is cheap to catch whether page
is LRU or non-lru movable once the page has been isolated. Because LRU
pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also
good for just peeking to test non-lru movable pages before more
expensive checking with lock_page in pfn scanning to select victim.
For guaranteeing non-lru movable page, VM provides PageMovable function.
Unlike __PageMovable, PageMovable functions validates page->mapping and
mapping->a_ops->isolate_page under lock_page. The lock_page prevents
sudden destroying of page->mapping.
Driver using __SetPageMovable should clear the flag via
__ClearMovablePage under page_lock before the releasing the page.
* PG_isolated
To prevent concurrent isolation among several CPUs, VM marks isolated
page as PG_isolated under lock_page. So if a CPU encounters PG_isolated
non-lru movable page, it can skip it. Driver doesn't need to manipulate
the flag because VM will set/clear it automatically. Keep in mind that
if driver sees PG_isolated page, it means the page have been isolated by
VM so it shouldn't touch page.lru field. PG_isolated is alias with
PG_reclaim flag so driver shouldn't use the flag for own purpose.
[opensource.ganesh@gmail.com: mm/compaction: remove local variable is_lru]
Link: http://lkml.kernel.org/r/20160618014841.GA7422@leo-test
Link: http://lkml.kernel.org/r/1464736881-24886-3-git-send-email-minchan@kernel.org
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: John Einar Reitan <john.reitan@foss.arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-07-27 06:23:05 +08:00
|
|
|
bool (*isolate_page) (struct page *, isolate_mode_t);
|
2010-12-16 19:04:54 +08:00
|
|
|
int (*migratepage)(struct address_space *, struct page *, struct page *);
|
mm: migrate: support non-lru movable page migration
We have allowed migration for only LRU pages until now and it was enough
to make high-order pages. But recently, embedded system(e.g., webOS,
android) uses lots of non-movable pages(e.g., zram, GPU memory) so we
have seen several reports about troubles of small high-order allocation.
For fixing the problem, there were several efforts (e,g,. enhance
compaction algorithm, SLUB fallback to 0-order page, reserved memory,
vmalloc and so on) but if there are lots of non-movable pages in system,
their solutions are void in the long run.
So, this patch is to support facility to change non-movable pages with
movable. For the feature, this patch introduces functions related to
migration to address_space_operations as well as some page flags.
If a driver want to make own pages movable, it should define three
functions which are function pointers of struct
address_space_operations.
1. bool (*isolate_page) (struct page *page, isolate_mode_t mode);
What VM expects on isolate_page function of driver is to return *true*
if driver isolates page successfully. On returing true, VM marks the
page as PG_isolated so concurrent isolation in several CPUs skip the
page for isolation. If a driver cannot isolate the page, it should
return *false*.
Once page is successfully isolated, VM uses page.lru fields so driver
shouldn't expect to preserve values in that fields.
2. int (*migratepage) (struct address_space *mapping,
struct page *newpage, struct page *oldpage, enum migrate_mode);
After isolation, VM calls migratepage of driver with isolated page. The
function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
indicate to the VM the oldpage is no longer movable via
__ClearPageMovable() under page_lock if you migrated the oldpage
successfully and returns 0. If driver cannot migrate the page at the
moment, driver can return -EAGAIN. On -EAGAIN, VM will retry page
migration in a short time because VM interprets -EAGAIN as "temporal
migration failure". On returning any error except -EAGAIN, VM will give
up the page migration without retrying in this time.
Driver shouldn't touch page.lru field VM using in the functions.
3. void (*putback_page)(struct page *);
If migration fails on isolated page, VM should return the isolated page
to the driver so VM calls driver's putback_page with migration failed
page. In this function, driver should put the isolated page back to the
own data structure.
4. non-lru movable page flags
There are two page flags for supporting non-lru movable page.
* PG_movable
Driver should use the below function to make page movable under
page_lock.
void __SetPageMovable(struct page *page, struct address_space *mapping)
It needs argument of address_space for registering migration family
functions which will be called by VM. Exactly speaking, PG_movable is
not a real flag of struct page. Rather than, VM reuses page->mapping's
lower bits to represent it.
#define PAGE_MAPPING_MOVABLE 0x2
page->mapping = page->mapping | PAGE_MAPPING_MOVABLE;
so driver shouldn't access page->mapping directly. Instead, driver
should use page_mapping which mask off the low two bits of page->mapping
so it can get right struct address_space.
For testing of non-lru movable page, VM supports __PageMovable function.
However, it doesn't guarantee to identify non-lru movable page because
page->mapping field is unified with other variables in struct page. As
well, if driver releases the page after isolation by VM, page->mapping
doesn't have stable value although it has PAGE_MAPPING_MOVABLE (Look at
__ClearPageMovable). But __PageMovable is cheap to catch whether page
is LRU or non-lru movable once the page has been isolated. Because LRU
pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also
good for just peeking to test non-lru movable pages before more
expensive checking with lock_page in pfn scanning to select victim.
For guaranteeing non-lru movable page, VM provides PageMovable function.
Unlike __PageMovable, PageMovable functions validates page->mapping and
mapping->a_ops->isolate_page under lock_page. The lock_page prevents
sudden destroying of page->mapping.
Driver using __SetPageMovable should clear the flag via
__ClearMovablePage under page_lock before the releasing the page.
* PG_isolated
To prevent concurrent isolation among several CPUs, VM marks isolated
page as PG_isolated under lock_page. So if a CPU encounters PG_isolated
non-lru movable page, it can skip it. Driver doesn't need to manipulate
the flag because VM will set/clear it automatically. Keep in mind that
if driver sees PG_isolated page, it means the page have been isolated by
VM so it shouldn't touch page.lru field. PG_isolated is alias with
PG_reclaim flag so driver shouldn't use the flag for own purpose.
[opensource.ganesh@gmail.com: mm/compaction: remove local variable is_lru]
Link: http://lkml.kernel.org/r/20160618014841.GA7422@leo-test
Link: http://lkml.kernel.org/r/1464736881-24886-3-git-send-email-minchan@kernel.org
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: John Einar Reitan <john.reitan@foss.arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-07-27 06:23:05 +08:00
|
|
|
void (*putback_page) (struct page *);
|
2010-12-16 19:04:54 +08:00
|
|
|
int (*launder_page)(struct page *);
|
2014-02-03 10:16:54 +08:00
|
|
|
int (*is_partially_uptodate)(struct page *, unsigned long, unsigned long);
|
2010-12-16 19:04:54 +08:00
|
|
|
int (*error_remove_page)(struct address_space *, struct page *);
|
2012-08-01 07:44:55 +08:00
|
|
|
int (*swap_activate)(struct file *);
|
|
|
|
|
int (*swap_deactivate)(struct file *);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
locking rules:
|
2010-12-02 02:35:19 +08:00
|
|
|
All except set_page_dirty and freepage may block
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-12-16 19:04:54 +08:00
|
|
|
PageLocked(page) i_mutex
|
|
|
|
|
writepage: yes, unlocks (see below)
|
|
|
|
|
readpage: yes, unlocks
|
|
|
|
|
writepages:
|
|
|
|
|
set_page_dirty no
|
|
|
|
|
readpages:
|
|
|
|
|
write_begin: locks the page yes
|
|
|
|
|
write_end: yes, unlocks yes
|
|
|
|
|
bmap:
|
|
|
|
|
invalidatepage: yes
|
|
|
|
|
releasepage: yes
|
|
|
|
|
freepage: yes
|
|
|
|
|
direct_IO:
|
mm: migrate: support non-lru movable page migration
We have allowed migration for only LRU pages until now and it was enough
to make high-order pages. But recently, embedded system(e.g., webOS,
android) uses lots of non-movable pages(e.g., zram, GPU memory) so we
have seen several reports about troubles of small high-order allocation.
For fixing the problem, there were several efforts (e,g,. enhance
compaction algorithm, SLUB fallback to 0-order page, reserved memory,
vmalloc and so on) but if there are lots of non-movable pages in system,
their solutions are void in the long run.
So, this patch is to support facility to change non-movable pages with
movable. For the feature, this patch introduces functions related to
migration to address_space_operations as well as some page flags.
If a driver want to make own pages movable, it should define three
functions which are function pointers of struct
address_space_operations.
1. bool (*isolate_page) (struct page *page, isolate_mode_t mode);
What VM expects on isolate_page function of driver is to return *true*
if driver isolates page successfully. On returing true, VM marks the
page as PG_isolated so concurrent isolation in several CPUs skip the
page for isolation. If a driver cannot isolate the page, it should
return *false*.
Once page is successfully isolated, VM uses page.lru fields so driver
shouldn't expect to preserve values in that fields.
2. int (*migratepage) (struct address_space *mapping,
struct page *newpage, struct page *oldpage, enum migrate_mode);
After isolation, VM calls migratepage of driver with isolated page. The
function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
indicate to the VM the oldpage is no longer movable via
__ClearPageMovable() under page_lock if you migrated the oldpage
successfully and returns 0. If driver cannot migrate the page at the
moment, driver can return -EAGAIN. On -EAGAIN, VM will retry page
migration in a short time because VM interprets -EAGAIN as "temporal
migration failure". On returning any error except -EAGAIN, VM will give
up the page migration without retrying in this time.
Driver shouldn't touch page.lru field VM using in the functions.
3. void (*putback_page)(struct page *);
If migration fails on isolated page, VM should return the isolated page
to the driver so VM calls driver's putback_page with migration failed
page. In this function, driver should put the isolated page back to the
own data structure.
4. non-lru movable page flags
There are two page flags for supporting non-lru movable page.
* PG_movable
Driver should use the below function to make page movable under
page_lock.
void __SetPageMovable(struct page *page, struct address_space *mapping)
It needs argument of address_space for registering migration family
functions which will be called by VM. Exactly speaking, PG_movable is
not a real flag of struct page. Rather than, VM reuses page->mapping's
lower bits to represent it.
#define PAGE_MAPPING_MOVABLE 0x2
page->mapping = page->mapping | PAGE_MAPPING_MOVABLE;
so driver shouldn't access page->mapping directly. Instead, driver
should use page_mapping which mask off the low two bits of page->mapping
so it can get right struct address_space.
For testing of non-lru movable page, VM supports __PageMovable function.
However, it doesn't guarantee to identify non-lru movable page because
page->mapping field is unified with other variables in struct page. As
well, if driver releases the page after isolation by VM, page->mapping
doesn't have stable value although it has PAGE_MAPPING_MOVABLE (Look at
__ClearPageMovable). But __PageMovable is cheap to catch whether page
is LRU or non-lru movable once the page has been isolated. Because LRU
pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also
good for just peeking to test non-lru movable pages before more
expensive checking with lock_page in pfn scanning to select victim.
For guaranteeing non-lru movable page, VM provides PageMovable function.
Unlike __PageMovable, PageMovable functions validates page->mapping and
mapping->a_ops->isolate_page under lock_page. The lock_page prevents
sudden destroying of page->mapping.
Driver using __SetPageMovable should clear the flag via
__ClearMovablePage under page_lock before the releasing the page.
* PG_isolated
To prevent concurrent isolation among several CPUs, VM marks isolated
page as PG_isolated under lock_page. So if a CPU encounters PG_isolated
non-lru movable page, it can skip it. Driver doesn't need to manipulate
the flag because VM will set/clear it automatically. Keep in mind that
if driver sees PG_isolated page, it means the page have been isolated by
VM so it shouldn't touch page.lru field. PG_isolated is alias with
PG_reclaim flag so driver shouldn't use the flag for own purpose.
[opensource.ganesh@gmail.com: mm/compaction: remove local variable is_lru]
Link: http://lkml.kernel.org/r/20160618014841.GA7422@leo-test
Link: http://lkml.kernel.org/r/1464736881-24886-3-git-send-email-minchan@kernel.org
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: John Einar Reitan <john.reitan@foss.arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-07-27 06:23:05 +08:00
|
|
|
isolate_page: yes
|
2010-12-16 19:04:54 +08:00
|
|
|
migratepage: yes (both)
|
mm: migrate: support non-lru movable page migration
We have allowed migration for only LRU pages until now and it was enough
to make high-order pages. But recently, embedded system(e.g., webOS,
android) uses lots of non-movable pages(e.g., zram, GPU memory) so we
have seen several reports about troubles of small high-order allocation.
For fixing the problem, there were several efforts (e,g,. enhance
compaction algorithm, SLUB fallback to 0-order page, reserved memory,
vmalloc and so on) but if there are lots of non-movable pages in system,
their solutions are void in the long run.
So, this patch is to support facility to change non-movable pages with
movable. For the feature, this patch introduces functions related to
migration to address_space_operations as well as some page flags.
If a driver want to make own pages movable, it should define three
functions which are function pointers of struct
address_space_operations.
1. bool (*isolate_page) (struct page *page, isolate_mode_t mode);
What VM expects on isolate_page function of driver is to return *true*
if driver isolates page successfully. On returing true, VM marks the
page as PG_isolated so concurrent isolation in several CPUs skip the
page for isolation. If a driver cannot isolate the page, it should
return *false*.
Once page is successfully isolated, VM uses page.lru fields so driver
shouldn't expect to preserve values in that fields.
2. int (*migratepage) (struct address_space *mapping,
struct page *newpage, struct page *oldpage, enum migrate_mode);
After isolation, VM calls migratepage of driver with isolated page. The
function of migratepage is to move content of the old page to new page
and set up fields of struct page newpage. Keep in mind that you should
indicate to the VM the oldpage is no longer movable via
__ClearPageMovable() under page_lock if you migrated the oldpage
successfully and returns 0. If driver cannot migrate the page at the
moment, driver can return -EAGAIN. On -EAGAIN, VM will retry page
migration in a short time because VM interprets -EAGAIN as "temporal
migration failure". On returning any error except -EAGAIN, VM will give
up the page migration without retrying in this time.
Driver shouldn't touch page.lru field VM using in the functions.
3. void (*putback_page)(struct page *);
If migration fails on isolated page, VM should return the isolated page
to the driver so VM calls driver's putback_page with migration failed
page. In this function, driver should put the isolated page back to the
own data structure.
4. non-lru movable page flags
There are two page flags for supporting non-lru movable page.
* PG_movable
Driver should use the below function to make page movable under
page_lock.
void __SetPageMovable(struct page *page, struct address_space *mapping)
It needs argument of address_space for registering migration family
functions which will be called by VM. Exactly speaking, PG_movable is
not a real flag of struct page. Rather than, VM reuses page->mapping's
lower bits to represent it.
#define PAGE_MAPPING_MOVABLE 0x2
page->mapping = page->mapping | PAGE_MAPPING_MOVABLE;
so driver shouldn't access page->mapping directly. Instead, driver
should use page_mapping which mask off the low two bits of page->mapping
so it can get right struct address_space.
For testing of non-lru movable page, VM supports __PageMovable function.
However, it doesn't guarantee to identify non-lru movable page because
page->mapping field is unified with other variables in struct page. As
well, if driver releases the page after isolation by VM, page->mapping
doesn't have stable value although it has PAGE_MAPPING_MOVABLE (Look at
__ClearPageMovable). But __PageMovable is cheap to catch whether page
is LRU or non-lru movable once the page has been isolated. Because LRU
pages never can have PAGE_MAPPING_MOVABLE in page->mapping. It is also
good for just peeking to test non-lru movable pages before more
expensive checking with lock_page in pfn scanning to select victim.
For guaranteeing non-lru movable page, VM provides PageMovable function.
Unlike __PageMovable, PageMovable functions validates page->mapping and
mapping->a_ops->isolate_page under lock_page. The lock_page prevents
sudden destroying of page->mapping.
Driver using __SetPageMovable should clear the flag via
__ClearMovablePage under page_lock before the releasing the page.
* PG_isolated
To prevent concurrent isolation among several CPUs, VM marks isolated
page as PG_isolated under lock_page. So if a CPU encounters PG_isolated
non-lru movable page, it can skip it. Driver doesn't need to manipulate
the flag because VM will set/clear it automatically. Keep in mind that
if driver sees PG_isolated page, it means the page have been isolated by
VM so it shouldn't touch page.lru field. PG_isolated is alias with
PG_reclaim flag so driver shouldn't use the flag for own purpose.
[opensource.ganesh@gmail.com: mm/compaction: remove local variable is_lru]
Link: http://lkml.kernel.org/r/20160618014841.GA7422@leo-test
Link: http://lkml.kernel.org/r/1464736881-24886-3-git-send-email-minchan@kernel.org
Signed-off-by: Gioh Kim <gi-oh.kim@profitbricks.com>
Signed-off-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Ganesh Mahendran <opensource.ganesh@gmail.com>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rafael Aquini <aquini@redhat.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: John Einar Reitan <john.reitan@foss.arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-07-27 06:23:05 +08:00
|
|
|
putback_page: yes
|
2010-12-16 19:04:54 +08:00
|
|
|
launder_page: yes
|
|
|
|
|
is_partially_uptodate: yes
|
|
|
|
|
error_remove_page: yes
|
2012-08-01 07:44:55 +08:00
|
|
|
swap_activate: no
|
|
|
|
|
swap_deactivate: no
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-03-07 12:27:26 +08:00
|
|
|
->write_begin(), ->write_end() and ->readpage() may be called from
|
|
|
|
|
the request handler (/dev/loop).
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
->readpage() unlocks the page, either synchronously or via I/O
|
|
|
|
|
completion.
|
|
|
|
|
|
|
|
|
|
->readpages() populates the pagecache with the passed pages and starts
|
|
|
|
|
I/O against them. They come unlocked upon I/O completion.
|
|
|
|
|
|
|
|
|
|
->writepage() is used for two purposes: for "memory cleansing" and for
|
|
|
|
|
"sync". These are quite different operations and the behaviour may differ
|
|
|
|
|
depending upon the mode.
|
|
|
|
|
|
|
|
|
|
If writepage is called for sync (wbc->sync_mode != WBC_SYNC_NONE) then
|
|
|
|
|
it *must* start I/O against the page, even if that would involve
|
|
|
|
|
blocking on in-progress I/O.
|
|
|
|
|
|
|
|
|
|
If writepage is called for memory cleansing (sync_mode ==
|
|
|
|
|
WBC_SYNC_NONE) then its role is to get as much writeout underway as
|
|
|
|
|
possible. So writepage should try to avoid blocking against
|
|
|
|
|
currently-in-progress I/O.
|
|
|
|
|
|
|
|
|
|
If the filesystem is not called for "sync" and it determines that it
|
|
|
|
|
would need to block against in-progress I/O to be able to start new I/O
|
|
|
|
|
against the page the filesystem should redirty the page with
|
|
|
|
|
redirty_page_for_writepage(), then unlock the page and return zero.
|
|
|
|
|
This may also be done to avoid internal deadlocks, but rarely.
|
|
|
|
|
|
2007-10-20 05:10:43 +08:00
|
|
|
If the filesystem is called for sync then it must wait on any
|
2005-04-17 06:20:36 +08:00
|
|
|
in-progress I/O and then start new I/O.
|
|
|
|
|
|
2005-05-01 23:58:37 +08:00
|
|
|
The filesystem should unlock the page synchronously, before returning to the
|
|
|
|
|
caller, unless ->writepage() returns special WRITEPAGE_ACTIVATE
|
|
|
|
|
value. WRITEPAGE_ACTIVATE means that page cannot really be written out
|
|
|
|
|
currently, and VM should stop calling ->writepage() on this page for some
|
|
|
|
|
time. VM does this by moving page to the head of the active list, hence the
|
|
|
|
|
name.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
Unless the filesystem is going to redirty_page_for_writepage(), unlock the page
|
|
|
|
|
and return zero, writepage *must* run set_page_writeback() against the page,
|
|
|
|
|
followed by unlocking it. Once set_page_writeback() has been run against the
|
|
|
|
|
page, write I/O can be submitted and the write I/O completion handler must run
|
|
|
|
|
end_page_writeback() once the I/O is complete. If no I/O is submitted, the
|
|
|
|
|
filesystem must run end_page_writeback() against the page before returning from
|
|
|
|
|
writepage.
|
|
|
|
|
|
|
|
|
|
That is: after 2.5.12, pages which are under writeout are *not* locked. Note,
|
|
|
|
|
if the filesystem needs the page to be locked during writeout, that is ok, too,
|
|
|
|
|
the page is allowed to be unlocked at any point in time between the calls to
|
|
|
|
|
set_page_writeback() and end_page_writeback().
|
|
|
|
|
|
|
|
|
|
Note, failure to run either redirty_page_for_writepage() or the combination of
|
|
|
|
|
set_page_writeback()/end_page_writeback() on a page submitted to writepage
|
|
|
|
|
will leave the page itself marked clean but it will be tagged as dirty in the
|
|
|
|
|
radix tree. This incoherency can lead to all sorts of hard-to-debug problems
|
|
|
|
|
in the filesystem like having dirty inodes at umount and losing written data.
|
|
|
|
|
|
|
|
|
|
->writepages() is used for periodic writeback and for syscall-initiated
|
|
|
|
|
sync operations. The address_space should start I/O against at least
|
|
|
|
|
*nr_to_write pages. *nr_to_write must be decremented for each page which is
|
|
|
|
|
written. The address_space implementation may write more (or less) pages
|
|
|
|
|
than *nr_to_write asks for, but it should try to be reasonably close. If
|
|
|
|
|
nr_to_write is NULL, all dirty pages must be written.
|
|
|
|
|
|
|
|
|
|
writepages should _only_ write pages which are present on
|
|
|
|
|
mapping->io_pages.
|
|
|
|
|
|
|
|
|
|
->set_page_dirty() is called from various places in the kernel
|
|
|
|
|
when the target page is marked as needing writeback. It may be called
|
|
|
|
|
under spinlock (it cannot block) and is sometimes called with the page
|
|
|
|
|
not locked.
|
|
|
|
|
|
|
|
|
|
->bmap() is currently used by legacy ioctl() (FIBMAP) provided by some
|
2010-12-16 19:04:54 +08:00
|
|
|
filesystems and by the swapper. The latter will eventually go away. Please,
|
|
|
|
|
keep it that way and don't breed new callers.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
->invalidatepage() is called when the filesystem must attempt to drop
|
2013-05-22 11:17:23 +08:00
|
|
|
some or all of the buffers from the page when it is being truncated. It
|
|
|
|
|
returns zero on success. If ->invalidatepage is zero, the kernel uses
|
2005-04-17 06:20:36 +08:00
|
|
|
block_invalidatepage() instead.
|
|
|
|
|
|
|
|
|
|
->releasepage() is called when the kernel is about to try to drop the
|
|
|
|
|
buffers from the page in preparation for freeing it. It returns zero to
|
|
|
|
|
indicate that the buffers are (or may be) freeable. If ->releasepage is zero,
|
|
|
|
|
the kernel assumes that the fs has no private interest in the buffers.
|
|
|
|
|
|
2010-12-02 02:35:19 +08:00
|
|
|
->freepage() is called when the kernel is done dropping the page
|
|
|
|
|
from the page cache.
|
|
|
|
|
|
2007-01-11 15:15:39 +08:00
|
|
|
->launder_page() may be called prior to releasing a page if
|
|
|
|
|
it is still found to be dirty. It returns zero if the page was successfully
|
|
|
|
|
cleaned, or an error value if not. Note that in order to prevent the page
|
|
|
|
|
getting mapped back in and redirtied, it needs to be kept locked
|
|
|
|
|
across the entire operation.
|
|
|
|
|
|
2012-08-01 07:44:55 +08:00
|
|
|
->swap_activate will be called with a non-zero argument on
|
|
|
|
|
files backing (non block device backed) swapfiles. A return value
|
|
|
|
|
of zero indicates success, in which case this file can be used for
|
|
|
|
|
backing swapspace. The swapspace operations will be proxied to the
|
|
|
|
|
address space operations.
|
|
|
|
|
|
|
|
|
|
->swap_deactivate() will be called in the sys_swapoff()
|
|
|
|
|
path after ->swap_activate() returned success.
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
----------------------- file_lock_operations ------------------------------
|
|
|
|
|
prototypes:
|
|
|
|
|
void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
|
|
|
|
|
void (*fl_release_private)(struct file_lock *);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
locking rules:
|
2013-06-21 20:58:15 +08:00
|
|
|
inode->i_lock may block
|
2010-12-16 19:04:54 +08:00
|
|
|
fl_copy_lock: yes no
|
2014-08-12 22:38:07 +08:00
|
|
|
fl_release_private: maybe maybe[1]
|
|
|
|
|
|
|
|
|
|
[1]: ->fl_release_private for flock or POSIX locks is currently allowed
|
|
|
|
|
to block. Leases however can still be freed while the i_lock is held and
|
|
|
|
|
so fl_release_private called on a lease should not block.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
----------------------- lock_manager_operations ---------------------------
|
|
|
|
|
prototypes:
|
2011-07-21 08:21:59 +08:00
|
|
|
int (*lm_compare_owner)(struct file_lock *, struct file_lock *);
|
2013-06-21 20:58:19 +08:00
|
|
|
unsigned long (*lm_owner_key)(struct file_lock *);
|
2011-07-21 08:21:59 +08:00
|
|
|
void (*lm_notify)(struct file_lock *); /* unblock callback */
|
|
|
|
|
int (*lm_grant)(struct file_lock *, struct file_lock *, int);
|
|
|
|
|
void (*lm_break)(struct file_lock *); /* break_lease callback */
|
|
|
|
|
int (*lm_change)(struct file_lock **, int);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
locking rules:
|
2013-06-21 20:58:15 +08:00
|
|
|
|
2013-06-21 20:58:20 +08:00
|
|
|
inode->i_lock blocked_lock_lock may block
|
|
|
|
|
lm_compare_owner: yes[1] maybe no
|
|
|
|
|
lm_owner_key yes[1] yes no
|
|
|
|
|
lm_notify: yes yes no
|
|
|
|
|
lm_grant: no no no
|
|
|
|
|
lm_break: yes no no
|
|
|
|
|
lm_change yes no no
|
2013-06-21 20:58:15 +08:00
|
|
|
|
2013-06-21 20:58:19 +08:00
|
|
|
[1]: ->lm_compare_owner and ->lm_owner_key are generally called with
|
|
|
|
|
*an* inode->i_lock held. It may not be the i_lock of the inode
|
|
|
|
|
associated with either file_lock argument! This is the case with deadlock
|
|
|
|
|
detection, since the code has to chase down the owners of locks that may
|
|
|
|
|
be entirely unrelated to the one on which the lock is being acquired.
|
2013-06-21 20:58:20 +08:00
|
|
|
For deadlock detection however, the blocked_lock_lock is also held. The
|
2013-06-21 20:58:19 +08:00
|
|
|
fact that these locks are held ensures that the file_locks do not
|
|
|
|
|
disappear out from under you while doing the comparison or generating an
|
|
|
|
|
owner key.
|
2010-12-16 19:04:54 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
--------------------------- buffer_head -----------------------------------
|
|
|
|
|
prototypes:
|
|
|
|
|
void (*b_end_io)(struct buffer_head *bh, int uptodate);
|
|
|
|
|
|
|
|
|
|
locking rules:
|
|
|
|
|
called from interrupts. In other words, extreme care is needed here.
|
|
|
|
|
bh is locked, but that's all warranties we have here. Currently only RAID1,
|
|
|
|
|
highmem, fs/buffer.c, and fs/ntfs/aops.c are providing these. Block devices
|
|
|
|
|
call this method upon the IO completion.
|
|
|
|
|
|
|
|
|
|
--------------------------- block_device_operations -----------------------
|
|
|
|
|
prototypes:
|
2010-10-06 16:46:53 +08:00
|
|
|
int (*open) (struct block_device *, fmode_t);
|
|
|
|
|
int (*release) (struct gendisk *, fmode_t);
|
|
|
|
|
int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
|
|
|
|
|
int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
|
2016-06-04 09:06:47 +08:00
|
|
|
int (*direct_access) (struct block_device *, sector_t, void **,
|
2015-08-19 03:55:41 +08:00
|
|
|
unsigned long *);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*media_changed) (struct gendisk *);
|
2010-10-06 16:46:53 +08:00
|
|
|
void (*unlock_native_capacity) (struct gendisk *);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*revalidate_disk) (struct gendisk *);
|
2010-10-06 16:46:53 +08:00
|
|
|
int (*getgeo)(struct block_device *, struct hd_geometry *);
|
|
|
|
|
void (*swap_slot_free_notify) (struct block_device *, unsigned long);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
locking rules:
|
2010-12-16 19:04:54 +08:00
|
|
|
bd_mutex
|
|
|
|
|
open: yes
|
|
|
|
|
release: yes
|
|
|
|
|
ioctl: no
|
|
|
|
|
compat_ioctl: no
|
|
|
|
|
direct_access: no
|
|
|
|
|
media_changed: no
|
|
|
|
|
unlock_native_capacity: no
|
|
|
|
|
revalidate_disk: no
|
|
|
|
|
getgeo: no
|
|
|
|
|
swap_slot_free_notify: no (see below)
|
2010-10-06 16:46:53 +08:00
|
|
|
|
|
|
|
|
media_changed, unlock_native_capacity and revalidate_disk are called only from
|
|
|
|
|
check_disk_change().
|
|
|
|
|
|
|
|
|
|
swap_slot_free_notify is called with swap_lock and sometimes the page lock
|
|
|
|
|
held.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
--------------------------- file_operations -------------------------------
|
|
|
|
|
prototypes:
|
|
|
|
|
loff_t (*llseek) (struct file *, loff_t, int);
|
|
|
|
|
ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
|
|
|
|
|
ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
|
2014-02-12 07:37:41 +08:00
|
|
|
ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
|
|
|
|
|
ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
|
2013-05-23 09:44:23 +08:00
|
|
|
int (*iterate) (struct file *, struct dir_context *);
|
2005-04-17 06:20:36 +08:00
|
|
|
unsigned int (*poll) (struct file *, struct poll_table_struct *);
|
|
|
|
|
long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
|
|
|
|
|
long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
|
|
|
|
|
int (*mmap) (struct file *, struct vm_area_struct *);
|
|
|
|
|
int (*open) (struct inode *, struct file *);
|
|
|
|
|
int (*flush) (struct file *);
|
|
|
|
|
int (*release) (struct inode *, struct file *);
|
2011-07-17 08:44:56 +08:00
|
|
|
int (*fsync) (struct file *, loff_t start, loff_t end, int datasync);
|
2005-04-17 06:20:36 +08:00
|
|
|
int (*fasync) (int, struct file *, int);
|
|
|
|
|
int (*lock) (struct file *, int, struct file_lock *);
|
|
|
|
|
ssize_t (*readv) (struct file *, const struct iovec *, unsigned long,
|
|
|
|
|
loff_t *);
|
|
|
|
|
ssize_t (*writev) (struct file *, const struct iovec *, unsigned long,
|
|
|
|
|
loff_t *);
|
|
|
|
|
ssize_t (*sendfile) (struct file *, loff_t *, size_t, read_actor_t,
|
|
|
|
|
void __user *);
|
|
|
|
|
ssize_t (*sendpage) (struct file *, struct page *, int, size_t,
|
|
|
|
|
loff_t *, int);
|
|
|
|
|
unsigned long (*get_unmapped_area)(struct file *, unsigned long,
|
|
|
|
|
unsigned long, unsigned long, unsigned long);
|
|
|
|
|
int (*check_flags)(int);
|
2010-12-16 19:04:54 +08:00
|
|
|
int (*flock) (struct file *, int, struct file_lock *);
|
|
|
|
|
ssize_t (*splice_write)(struct pipe_inode_info *, struct file *, loff_t *,
|
|
|
|
|
size_t, unsigned int);
|
|
|
|
|
ssize_t (*splice_read)(struct file *, loff_t *, struct pipe_inode_info *,
|
|
|
|
|
size_t, unsigned int);
|
2014-08-22 22:40:25 +08:00
|
|
|
int (*setlease)(struct file *, long, struct file_lock **, void **);
|
2011-01-14 20:07:43 +08:00
|
|
|
long (*fallocate)(struct file *, int, loff_t, loff_t);
|
2005-04-17 06:20:36 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
locking rules:
|
2014-09-01 19:12:07 +08:00
|
|
|
All may block.
|
2010-12-16 19:04:54 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
->llseek() locking has moved from llseek to the individual llseek
|
|
|
|
|
implementations. If your fs is not using generic_file_llseek, you
|
|
|
|
|
need to acquire and release the appropriate locks in your ->llseek().
|
|
|
|
|
For many filesystems, it is probably safe to acquire the inode
|
2010-05-27 05:44:54 +08:00
|
|
|
mutex or just to use i_size_read() instead.
|
|
|
|
|
Note: this does not protect the file->f_pos against concurrent modifications
|
|
|
|
|
since this is something the userspace has to take care about.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2010-12-16 19:04:54 +08:00
|
|
|
->fasync() is responsible for maintaining the FASYNC bit in filp->f_flags.
|
|
|
|
|
Most instances call fasync_helper(), which does that maintenance, so it's
|
|
|
|
|
not normally something one needs to worry about. Return values > 0 will be
|
|
|
|
|
mapped to zero in the VFS layer.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
->readdir() and ->ioctl() on directories must be changed. Ideally we would
|
|
|
|
|
move ->readdir() to inode_operations and use a separate method for directory
|
|
|
|
|
->ioctl() or kill the latter completely. One of the problems is that for
|
|
|
|
|
anything that resembles union-mount we won't have a struct file for all
|
|
|
|
|
components. And there are other reasons why the current interface is a mess...
|
|
|
|
|
|
|
|
|
|
->read on directories probably must go away - we should just enforce -EISDIR
|
|
|
|
|
in sys_read() and friends.
|
|
|
|
|
|
2014-08-23 06:50:48 +08:00
|
|
|
->setlease operations should call generic_setlease() before or after setting
|
|
|
|
|
the lease within the individual filesystem to record the result of the
|
|
|
|
|
operation
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
--------------------------- dquot_operations -------------------------------
|
|
|
|
|
prototypes:
|
|
|
|
|
int (*write_dquot) (struct dquot *);
|
|
|
|
|
int (*acquire_dquot) (struct dquot *);
|
|
|
|
|
int (*release_dquot) (struct dquot *);
|
|
|
|
|
int (*mark_dirty) (struct dquot *);
|
|
|
|
|
int (*write_info) (struct super_block *, int);
|
|
|
|
|
|
|
|
|
|
These operations are intended to be more or less wrapping functions that ensure
|
|
|
|
|
a proper locking wrt the filesystem and call the generic quota operations.
|
|
|
|
|
|
|
|
|
|
What filesystem should expect from the generic quota functions:
|
|
|
|
|
|
|
|
|
|
FS recursion Held locks when called
|
|
|
|
|
write_dquot: yes dqonoff_sem or dqptr_sem
|
|
|
|
|
acquire_dquot: yes dqonoff_sem or dqptr_sem
|
|
|
|
|
release_dquot: yes dqonoff_sem or dqptr_sem
|
|
|
|
|
mark_dirty: no -
|
|
|
|
|
write_info: yes dqonoff_sem
|
|
|
|
|
|
|
|
|
|
FS recursion means calling ->quota_read() and ->quota_write() from superblock
|
|
|
|
|
operations.
|
|
|
|
|
|
|
|
|
|
More details about quota locking can be found in fs/dquot.c.
|
|
|
|
|
|
|
|
|
|
--------------------------- vm_operations_struct -----------------------------
|
|
|
|
|
prototypes:
|
|
|
|
|
void (*open)(struct vm_area_struct*);
|
|
|
|
|
void (*close)(struct vm_area_struct*);
|
2007-07-19 16:47:03 +08:00
|
|
|
int (*fault)(struct vm_area_struct*, struct vm_fault *);
|
2009-04-01 06:23:21 +08:00
|
|
|
int (*page_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
2015-04-16 07:15:11 +08:00
|
|
|
int (*pfn_mkwrite)(struct vm_area_struct *, struct vm_fault *);
|
2008-07-24 12:27:05 +08:00
|
|
|
int (*access)(struct vm_area_struct *, unsigned long, void*, int, int);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
|
|
|
|
locking rules:
|
2010-12-16 19:04:54 +08:00
|
|
|
mmap_sem PageLocked(page)
|
|
|
|
|
open: yes
|
|
|
|
|
close: yes
|
|
|
|
|
fault: yes can return with page locked
|
mm: introduce vm_ops->map_pages()
Here's new version of faultaround patchset. It took a while to tune it
and collect performance data.
First patch adds new callback ->map_pages to vm_operations_struct.
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from
"pgoff" till "max_pgoff". ->map_pages() is called with page table
locked and must not block. If it's not possible to reach a page without
blocking, filesystem should skip it. Filesystem should use do_set_pte()
to setup page table entry. Pointer to entry associated with offset
"pgoff" is passed in "pte" field in vm_fault structure. Pointers to
entries for other offsets should be calculated relative to "pte".
Currently VM use ->map_pages only on read page fault path. We try to
map FAULT_AROUND_PAGES a time. FAULT_AROUND_PAGES is 16 for now.
Performance data for different FAULT_AROUND_ORDER is below.
TODO:
- implement ->map_pages() for shmem/tmpfs;
- modify get_user_pages() to be able to use ->map_pages() and implement
mmap(MAP_POPULATE|MAP_NONBLOCK) on top.
=========================================================================
Tested on 4-socket machine (120 threads) with 128GiB of RAM.
Few real-world workloads. The sweet spot for FAULT_AROUND_ORDER here is
somewhere between 3 and 5. Let's say 4 :)
Linux build (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 283,301,572 247,151,987 212,215,789 204,772,882 199,568,944 194,703,779 193,381,485
time, seconds 151.227629483 153.920996480 151.356125472 150.863792049 150.879207877 151.150764954 151.450962358
Linux rebuild (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 5,396,854 4,148,444 2,855,286 2,577,282 2,361,957 2,169,573 2,112,643
time, seconds 27.404543757 27.559725591 27.030057426 26.855045126 26.678618635 26.974523490 26.761320095
Git test suite (make -j60 test)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 129,591,823 99,200,751 66,106,718 57,606,410 51,510,808 45,776,813 44,085,515
time, seconds 66.087215026 64.784546905 64.401156567 65.282708668 66.034016829 66.793780811 67.237810413
Two synthetic tests: access every word in file in sequential/random order.
It doesn't improve much after FAULT_AROUND_ORDER == 4.
Sequential access 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 4,195,437 2,098,275 525,068 262,251 131,170 32,856 8,282
time, seconds 7.250461742 6.461711074 5.493859139 5.488488147 5.707213983 5.898510832 5.109232856
8 threads
minor-faults 33,557,540 16,892,728 4,515,848 2,366,999 1,423,382 442,732 142,339
time, seconds 16.649304881 9.312555263 6.612490639 6.394316732 6.669827501 6.75078944 6.371900528
32 threads
minor-faults 134,228,222 67,526,810 17,725,386 9,716,537 4,763,731 1,668,921 537,200
time, seconds 49.164430543 29.712060103 12.938649729 10.175151004 11.840094583 9.594081325 9.928461797
60 threads
minor-faults 251,687,988 126,146,952 32,919,406 18,208,804 10,458,947 2,733,907 928,217
time, seconds 86.260656897 49.626551828 22.335007632 17.608243696 16.523119035 16.339489186 16.326390902
120 threads
minor-faults 503,352,863 252,939,677 67,039,168 35,191,827 19,170,091 4,688,357 1,471,862
time, seconds 124.589206333 79.757867787 39.508707872 32.167281632 29.972989292 28.729834575 28.042251622
Random access 1GiB file
1 thread
minor-faults 262,636 132,743 34,369 17,299 8,527 3,451 1,222
time, seconds 15.351890914 16.613802482 16.569227308 15.179220992 16.557356122 16.578247824 15.365266994
8 threads
minor-faults 2,098,948 1,061,871 273,690 154,501 87,110 25,663 7,384
time, seconds 15.040026343 15.096933500 14.474757288 14.289129964 14.411537468 14.296316837 14.395635804
32 threads
minor-faults 8,390,734 4,231,023 1,054,432 528,847 269,242 97,746 26,881
time, seconds 20.430433109 21.585235358 22.115062928 14.872878951 14.880856305 14.883370649 14.821261690
60 threads
minor-faults 15,733,258 7,892,809 1,973,393 988,266 594,789 164,994 51,691
time, seconds 26.577302548 25.692397770 18.728863715 20.153026398 21.619101933 17.745086260 17.613215273
120 threads
minor-faults 31,471,111 15,816,616 3,959,209 1,978,685 1,008,299 264,635 96,010
time, seconds 41.835322703 40.459786095 36.085306105 35.313894834 35.814445675 36.552633793 34.289210594
Touch only one page in page table in 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 8,372 8,324 8,270 8,260 8,249 8,239 8,237
time, seconds 0.039892712 0.045369149 0.051846126 0.063681685 0.079095975 0.17652406 0.541213386
8 threads
minor-faults 65,731 65,681 65,628 65,620 65,608 65,599 65,596
time, seconds 0.124159196 0.488600638 0.156854426 0.191901957 0.242631486 0.543569456 1.677303984
32 threads
minor-faults 262,388 262,341 262,285 262,276 262,266 262,257 263,183
time, seconds 0.452421421 0.488600638 0.565020946 0.648229739 0.789850823 1.651584361 5.000361559
60 threads
minor-faults 491,822 491,792 491,723 491,711 491,701 491,691 491,825
time, seconds 0.763288616 0.869620515 0.980727360 1.161732354 1.466915814 3.04041448 9.308612938
120 threads
minor-faults 983,466 983,655 983,366 983,372 983,363 984,083 984,164
time, seconds 1.595846553 1.667902182 2.008959376 2.425380942 2.941368804 5.977807890 18.401846125
This patch (of 2):
Introduce new vm_ops callback ->map_pages() and uses it for mapping easy
accessible pages around fault address.
On read page fault, if filesystem provides ->map_pages(), we try to map up
to FAULT_AROUND_PAGES pages around page fault address in hope to reduce
number of minor page faults.
We call ->map_pages first and use ->fault() as fallback if page by the
offset is not ready to be mapped (cold page cache or something).
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ning Qu <quning@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-08 06:37:18 +08:00
|
|
|
map_pages: yes
|
2010-12-16 19:04:54 +08:00
|
|
|
page_mkwrite: yes can return with page locked
|
2015-04-16 07:15:11 +08:00
|
|
|
pfn_mkwrite: yes
|
2010-12-16 19:04:54 +08:00
|
|
|
access: yes
|
2007-07-19 16:47:01 +08:00
|
|
|
|
mm: close page_mkwrite races
Change page_mkwrite to allow implementations to return with the page
locked, and also change it's callers (in page fault paths) to hold the
lock until the page is marked dirty. This allows the filesystem to have
full control of page dirtying events coming from the VM.
Rather than simply hold the page locked over the page_mkwrite call, we
call page_mkwrite with the page unlocked and allow callers to return with
it locked, so filesystems can avoid LOR conditions with page lock.
The problem with the current scheme is this: a filesystem that wants to
associate some metadata with a page as long as the page is dirty, will
perform this manipulation in its ->page_mkwrite. It currently then must
return with the page unlocked and may not hold any other locks (according
to existing page_mkwrite convention).
In this window, the VM could write out the page, clearing page-dirty. The
filesystem has no good way to detect that a dirty pte is about to be
attached, so it will happily write out the page, at which point, the
filesystem may manipulate the metadata to reflect that the page is no
longer dirty.
It is not always possible to perform the required metadata manipulation in
->set_page_dirty, because that function cannot block or fail. The
filesystem may need to allocate some data structure, for example.
And the VM cannot mark the pte dirty before page_mkwrite, because
page_mkwrite is allowed to fail, so we must not allow any window where the
page could be written to if page_mkwrite does fail.
This solution of holding the page locked over the 3 critical operations
(page_mkwrite, setting the pte dirty, and finally setting the page dirty)
closes out races nicely, preventing page cleaning for writeout being
initiated in that window. This provides the filesystem with a strong
synchronisation against the VM here.
- Sage needs this race closed for ceph filesystem.
- Trond for NFS (http://bugzilla.kernel.org/show_bug.cgi?id=12913).
- I need it for fsblock.
- I suspect other filesystems may need it too (eg. btrfs).
- I have converted buffer.c to the new locking. Even simple block allocation
under dirty pages might be susceptible to i_size changing under partial page
at the end of file (we also have a buffer.c-side problem here, but it cannot
be fixed properly without this patch).
- Other filesystems (eg. NFS, maybe btrfs) will need to change their
page_mkwrite functions themselves.
[ This also moves page_mkwrite another step closer to fault, which should
eventually allow page_mkwrite to be moved into ->fault, and thus avoiding a
filesystem calldown and page lock/unlock cycle in __do_fault. ]
[akpm@linux-foundation.org: fix derefs of NULL ->mapping]
Cc: Sage Weil <sage@newdream.net>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-01 06:08:16 +08:00
|
|
|
->fault() is called when a previously not present pte is about
|
|
|
|
|
to be faulted in. The filesystem must find and return the page associated
|
|
|
|
|
with the passed in "pgoff" in the vm_fault structure. If it is possible that
|
|
|
|
|
the page may be truncated and/or invalidated, then the filesystem must lock
|
|
|
|
|
the page, then ensure it is not already truncated (the page lock will block
|
|
|
|
|
subsequent truncate), and then return with VM_FAULT_LOCKED, and the page
|
|
|
|
|
locked. The VM will unlock the page.
|
|
|
|
|
|
mm: introduce vm_ops->map_pages()
Here's new version of faultaround patchset. It took a while to tune it
and collect performance data.
First patch adds new callback ->map_pages to vm_operations_struct.
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from
"pgoff" till "max_pgoff". ->map_pages() is called with page table
locked and must not block. If it's not possible to reach a page without
blocking, filesystem should skip it. Filesystem should use do_set_pte()
to setup page table entry. Pointer to entry associated with offset
"pgoff" is passed in "pte" field in vm_fault structure. Pointers to
entries for other offsets should be calculated relative to "pte".
Currently VM use ->map_pages only on read page fault path. We try to
map FAULT_AROUND_PAGES a time. FAULT_AROUND_PAGES is 16 for now.
Performance data for different FAULT_AROUND_ORDER is below.
TODO:
- implement ->map_pages() for shmem/tmpfs;
- modify get_user_pages() to be able to use ->map_pages() and implement
mmap(MAP_POPULATE|MAP_NONBLOCK) on top.
=========================================================================
Tested on 4-socket machine (120 threads) with 128GiB of RAM.
Few real-world workloads. The sweet spot for FAULT_AROUND_ORDER here is
somewhere between 3 and 5. Let's say 4 :)
Linux build (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 283,301,572 247,151,987 212,215,789 204,772,882 199,568,944 194,703,779 193,381,485
time, seconds 151.227629483 153.920996480 151.356125472 150.863792049 150.879207877 151.150764954 151.450962358
Linux rebuild (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 5,396,854 4,148,444 2,855,286 2,577,282 2,361,957 2,169,573 2,112,643
time, seconds 27.404543757 27.559725591 27.030057426 26.855045126 26.678618635 26.974523490 26.761320095
Git test suite (make -j60 test)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 129,591,823 99,200,751 66,106,718 57,606,410 51,510,808 45,776,813 44,085,515
time, seconds 66.087215026 64.784546905 64.401156567 65.282708668 66.034016829 66.793780811 67.237810413
Two synthetic tests: access every word in file in sequential/random order.
It doesn't improve much after FAULT_AROUND_ORDER == 4.
Sequential access 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 4,195,437 2,098,275 525,068 262,251 131,170 32,856 8,282
time, seconds 7.250461742 6.461711074 5.493859139 5.488488147 5.707213983 5.898510832 5.109232856
8 threads
minor-faults 33,557,540 16,892,728 4,515,848 2,366,999 1,423,382 442,732 142,339
time, seconds 16.649304881 9.312555263 6.612490639 6.394316732 6.669827501 6.75078944 6.371900528
32 threads
minor-faults 134,228,222 67,526,810 17,725,386 9,716,537 4,763,731 1,668,921 537,200
time, seconds 49.164430543 29.712060103 12.938649729 10.175151004 11.840094583 9.594081325 9.928461797
60 threads
minor-faults 251,687,988 126,146,952 32,919,406 18,208,804 10,458,947 2,733,907 928,217
time, seconds 86.260656897 49.626551828 22.335007632 17.608243696 16.523119035 16.339489186 16.326390902
120 threads
minor-faults 503,352,863 252,939,677 67,039,168 35,191,827 19,170,091 4,688,357 1,471,862
time, seconds 124.589206333 79.757867787 39.508707872 32.167281632 29.972989292 28.729834575 28.042251622
Random access 1GiB file
1 thread
minor-faults 262,636 132,743 34,369 17,299 8,527 3,451 1,222
time, seconds 15.351890914 16.613802482 16.569227308 15.179220992 16.557356122 16.578247824 15.365266994
8 threads
minor-faults 2,098,948 1,061,871 273,690 154,501 87,110 25,663 7,384
time, seconds 15.040026343 15.096933500 14.474757288 14.289129964 14.411537468 14.296316837 14.395635804
32 threads
minor-faults 8,390,734 4,231,023 1,054,432 528,847 269,242 97,746 26,881
time, seconds 20.430433109 21.585235358 22.115062928 14.872878951 14.880856305 14.883370649 14.821261690
60 threads
minor-faults 15,733,258 7,892,809 1,973,393 988,266 594,789 164,994 51,691
time, seconds 26.577302548 25.692397770 18.728863715 20.153026398 21.619101933 17.745086260 17.613215273
120 threads
minor-faults 31,471,111 15,816,616 3,959,209 1,978,685 1,008,299 264,635 96,010
time, seconds 41.835322703 40.459786095 36.085306105 35.313894834 35.814445675 36.552633793 34.289210594
Touch only one page in page table in 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 8,372 8,324 8,270 8,260 8,249 8,239 8,237
time, seconds 0.039892712 0.045369149 0.051846126 0.063681685 0.079095975 0.17652406 0.541213386
8 threads
minor-faults 65,731 65,681 65,628 65,620 65,608 65,599 65,596
time, seconds 0.124159196 0.488600638 0.156854426 0.191901957 0.242631486 0.543569456 1.677303984
32 threads
minor-faults 262,388 262,341 262,285 262,276 262,266 262,257 263,183
time, seconds 0.452421421 0.488600638 0.565020946 0.648229739 0.789850823 1.651584361 5.000361559
60 threads
minor-faults 491,822 491,792 491,723 491,711 491,701 491,691 491,825
time, seconds 0.763288616 0.869620515 0.980727360 1.161732354 1.466915814 3.04041448 9.308612938
120 threads
minor-faults 983,466 983,655 983,366 983,372 983,363 984,083 984,164
time, seconds 1.595846553 1.667902182 2.008959376 2.425380942 2.941368804 5.977807890 18.401846125
This patch (of 2):
Introduce new vm_ops callback ->map_pages() and uses it for mapping easy
accessible pages around fault address.
On read page fault, if filesystem provides ->map_pages(), we try to map up
to FAULT_AROUND_PAGES pages around page fault address in hope to reduce
number of minor page faults.
We call ->map_pages first and use ->fault() as fallback if page by the
offset is not ready to be mapped (cold page cache or something).
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ning Qu <quning@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-08 06:37:18 +08:00
|
|
|
->map_pages() is called when VM asks to map easy accessible pages.
|
2016-07-27 06:25:20 +08:00
|
|
|
Filesystem should find and map pages associated with offsets from "start_pgoff"
|
|
|
|
|
till "end_pgoff". ->map_pages() is called with page table locked and must
|
mm: introduce vm_ops->map_pages()
Here's new version of faultaround patchset. It took a while to tune it
and collect performance data.
First patch adds new callback ->map_pages to vm_operations_struct.
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from
"pgoff" till "max_pgoff". ->map_pages() is called with page table
locked and must not block. If it's not possible to reach a page without
blocking, filesystem should skip it. Filesystem should use do_set_pte()
to setup page table entry. Pointer to entry associated with offset
"pgoff" is passed in "pte" field in vm_fault structure. Pointers to
entries for other offsets should be calculated relative to "pte".
Currently VM use ->map_pages only on read page fault path. We try to
map FAULT_AROUND_PAGES a time. FAULT_AROUND_PAGES is 16 for now.
Performance data for different FAULT_AROUND_ORDER is below.
TODO:
- implement ->map_pages() for shmem/tmpfs;
- modify get_user_pages() to be able to use ->map_pages() and implement
mmap(MAP_POPULATE|MAP_NONBLOCK) on top.
=========================================================================
Tested on 4-socket machine (120 threads) with 128GiB of RAM.
Few real-world workloads. The sweet spot for FAULT_AROUND_ORDER here is
somewhere between 3 and 5. Let's say 4 :)
Linux build (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 283,301,572 247,151,987 212,215,789 204,772,882 199,568,944 194,703,779 193,381,485
time, seconds 151.227629483 153.920996480 151.356125472 150.863792049 150.879207877 151.150764954 151.450962358
Linux rebuild (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 5,396,854 4,148,444 2,855,286 2,577,282 2,361,957 2,169,573 2,112,643
time, seconds 27.404543757 27.559725591 27.030057426 26.855045126 26.678618635 26.974523490 26.761320095
Git test suite (make -j60 test)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 129,591,823 99,200,751 66,106,718 57,606,410 51,510,808 45,776,813 44,085,515
time, seconds 66.087215026 64.784546905 64.401156567 65.282708668 66.034016829 66.793780811 67.237810413
Two synthetic tests: access every word in file in sequential/random order.
It doesn't improve much after FAULT_AROUND_ORDER == 4.
Sequential access 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 4,195,437 2,098,275 525,068 262,251 131,170 32,856 8,282
time, seconds 7.250461742 6.461711074 5.493859139 5.488488147 5.707213983 5.898510832 5.109232856
8 threads
minor-faults 33,557,540 16,892,728 4,515,848 2,366,999 1,423,382 442,732 142,339
time, seconds 16.649304881 9.312555263 6.612490639 6.394316732 6.669827501 6.75078944 6.371900528
32 threads
minor-faults 134,228,222 67,526,810 17,725,386 9,716,537 4,763,731 1,668,921 537,200
time, seconds 49.164430543 29.712060103 12.938649729 10.175151004 11.840094583 9.594081325 9.928461797
60 threads
minor-faults 251,687,988 126,146,952 32,919,406 18,208,804 10,458,947 2,733,907 928,217
time, seconds 86.260656897 49.626551828 22.335007632 17.608243696 16.523119035 16.339489186 16.326390902
120 threads
minor-faults 503,352,863 252,939,677 67,039,168 35,191,827 19,170,091 4,688,357 1,471,862
time, seconds 124.589206333 79.757867787 39.508707872 32.167281632 29.972989292 28.729834575 28.042251622
Random access 1GiB file
1 thread
minor-faults 262,636 132,743 34,369 17,299 8,527 3,451 1,222
time, seconds 15.351890914 16.613802482 16.569227308 15.179220992 16.557356122 16.578247824 15.365266994
8 threads
minor-faults 2,098,948 1,061,871 273,690 154,501 87,110 25,663 7,384
time, seconds 15.040026343 15.096933500 14.474757288 14.289129964 14.411537468 14.296316837 14.395635804
32 threads
minor-faults 8,390,734 4,231,023 1,054,432 528,847 269,242 97,746 26,881
time, seconds 20.430433109 21.585235358 22.115062928 14.872878951 14.880856305 14.883370649 14.821261690
60 threads
minor-faults 15,733,258 7,892,809 1,973,393 988,266 594,789 164,994 51,691
time, seconds 26.577302548 25.692397770 18.728863715 20.153026398 21.619101933 17.745086260 17.613215273
120 threads
minor-faults 31,471,111 15,816,616 3,959,209 1,978,685 1,008,299 264,635 96,010
time, seconds 41.835322703 40.459786095 36.085306105 35.313894834 35.814445675 36.552633793 34.289210594
Touch only one page in page table in 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 8,372 8,324 8,270 8,260 8,249 8,239 8,237
time, seconds 0.039892712 0.045369149 0.051846126 0.063681685 0.079095975 0.17652406 0.541213386
8 threads
minor-faults 65,731 65,681 65,628 65,620 65,608 65,599 65,596
time, seconds 0.124159196 0.488600638 0.156854426 0.191901957 0.242631486 0.543569456 1.677303984
32 threads
minor-faults 262,388 262,341 262,285 262,276 262,266 262,257 263,183
time, seconds 0.452421421 0.488600638 0.565020946 0.648229739 0.789850823 1.651584361 5.000361559
60 threads
minor-faults 491,822 491,792 491,723 491,711 491,701 491,691 491,825
time, seconds 0.763288616 0.869620515 0.980727360 1.161732354 1.466915814 3.04041448 9.308612938
120 threads
minor-faults 983,466 983,655 983,366 983,372 983,363 984,083 984,164
time, seconds 1.595846553 1.667902182 2.008959376 2.425380942 2.941368804 5.977807890 18.401846125
This patch (of 2):
Introduce new vm_ops callback ->map_pages() and uses it for mapping easy
accessible pages around fault address.
On read page fault, if filesystem provides ->map_pages(), we try to map up
to FAULT_AROUND_PAGES pages around page fault address in hope to reduce
number of minor page faults.
We call ->map_pages first and use ->fault() as fallback if page by the
offset is not ready to be mapped (cold page cache or something).
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ning Qu <quning@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-08 06:37:18 +08:00
|
|
|
not block. If it's not possible to reach a page without blocking,
|
|
|
|
|
filesystem should skip it. Filesystem should use do_set_pte() to setup
|
2016-07-27 06:25:20 +08:00
|
|
|
page table entry. Pointer to entry associated with the page is passed in
|
2016-12-15 07:06:58 +08:00
|
|
|
"pte" field in vm_fault structure. Pointers to entries for other offsets
|
2016-07-27 06:25:20 +08:00
|
|
|
should be calculated relative to "pte".
|
mm: introduce vm_ops->map_pages()
Here's new version of faultaround patchset. It took a while to tune it
and collect performance data.
First patch adds new callback ->map_pages to vm_operations_struct.
->map_pages() is called when VM asks to map easy accessible pages.
Filesystem should find and map pages associated with offsets from
"pgoff" till "max_pgoff". ->map_pages() is called with page table
locked and must not block. If it's not possible to reach a page without
blocking, filesystem should skip it. Filesystem should use do_set_pte()
to setup page table entry. Pointer to entry associated with offset
"pgoff" is passed in "pte" field in vm_fault structure. Pointers to
entries for other offsets should be calculated relative to "pte".
Currently VM use ->map_pages only on read page fault path. We try to
map FAULT_AROUND_PAGES a time. FAULT_AROUND_PAGES is 16 for now.
Performance data for different FAULT_AROUND_ORDER is below.
TODO:
- implement ->map_pages() for shmem/tmpfs;
- modify get_user_pages() to be able to use ->map_pages() and implement
mmap(MAP_POPULATE|MAP_NONBLOCK) on top.
=========================================================================
Tested on 4-socket machine (120 threads) with 128GiB of RAM.
Few real-world workloads. The sweet spot for FAULT_AROUND_ORDER here is
somewhere between 3 and 5. Let's say 4 :)
Linux build (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 283,301,572 247,151,987 212,215,789 204,772,882 199,568,944 194,703,779 193,381,485
time, seconds 151.227629483 153.920996480 151.356125472 150.863792049 150.879207877 151.150764954 151.450962358
Linux rebuild (make -j60)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 5,396,854 4,148,444 2,855,286 2,577,282 2,361,957 2,169,573 2,112,643
time, seconds 27.404543757 27.559725591 27.030057426 26.855045126 26.678618635 26.974523490 26.761320095
Git test suite (make -j60 test)
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
minor-faults 129,591,823 99,200,751 66,106,718 57,606,410 51,510,808 45,776,813 44,085,515
time, seconds 66.087215026 64.784546905 64.401156567 65.282708668 66.034016829 66.793780811 67.237810413
Two synthetic tests: access every word in file in sequential/random order.
It doesn't improve much after FAULT_AROUND_ORDER == 4.
Sequential access 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 4,195,437 2,098,275 525,068 262,251 131,170 32,856 8,282
time, seconds 7.250461742 6.461711074 5.493859139 5.488488147 5.707213983 5.898510832 5.109232856
8 threads
minor-faults 33,557,540 16,892,728 4,515,848 2,366,999 1,423,382 442,732 142,339
time, seconds 16.649304881 9.312555263 6.612490639 6.394316732 6.669827501 6.75078944 6.371900528
32 threads
minor-faults 134,228,222 67,526,810 17,725,386 9,716,537 4,763,731 1,668,921 537,200
time, seconds 49.164430543 29.712060103 12.938649729 10.175151004 11.840094583 9.594081325 9.928461797
60 threads
minor-faults 251,687,988 126,146,952 32,919,406 18,208,804 10,458,947 2,733,907 928,217
time, seconds 86.260656897 49.626551828 22.335007632 17.608243696 16.523119035 16.339489186 16.326390902
120 threads
minor-faults 503,352,863 252,939,677 67,039,168 35,191,827 19,170,091 4,688,357 1,471,862
time, seconds 124.589206333 79.757867787 39.508707872 32.167281632 29.972989292 28.729834575 28.042251622
Random access 1GiB file
1 thread
minor-faults 262,636 132,743 34,369 17,299 8,527 3,451 1,222
time, seconds 15.351890914 16.613802482 16.569227308 15.179220992 16.557356122 16.578247824 15.365266994
8 threads
minor-faults 2,098,948 1,061,871 273,690 154,501 87,110 25,663 7,384
time, seconds 15.040026343 15.096933500 14.474757288 14.289129964 14.411537468 14.296316837 14.395635804
32 threads
minor-faults 8,390,734 4,231,023 1,054,432 528,847 269,242 97,746 26,881
time, seconds 20.430433109 21.585235358 22.115062928 14.872878951 14.880856305 14.883370649 14.821261690
60 threads
minor-faults 15,733,258 7,892,809 1,973,393 988,266 594,789 164,994 51,691
time, seconds 26.577302548 25.692397770 18.728863715 20.153026398 21.619101933 17.745086260 17.613215273
120 threads
minor-faults 31,471,111 15,816,616 3,959,209 1,978,685 1,008,299 264,635 96,010
time, seconds 41.835322703 40.459786095 36.085306105 35.313894834 35.814445675 36.552633793 34.289210594
Touch only one page in page table in 16GiB file
FAULT_AROUND_ORDER Baseline 1 3 4 5 7 9
1 thread
minor-faults 8,372 8,324 8,270 8,260 8,249 8,239 8,237
time, seconds 0.039892712 0.045369149 0.051846126 0.063681685 0.079095975 0.17652406 0.541213386
8 threads
minor-faults 65,731 65,681 65,628 65,620 65,608 65,599 65,596
time, seconds 0.124159196 0.488600638 0.156854426 0.191901957 0.242631486 0.543569456 1.677303984
32 threads
minor-faults 262,388 262,341 262,285 262,276 262,266 262,257 263,183
time, seconds 0.452421421 0.488600638 0.565020946 0.648229739 0.789850823 1.651584361 5.000361559
60 threads
minor-faults 491,822 491,792 491,723 491,711 491,701 491,691 491,825
time, seconds 0.763288616 0.869620515 0.980727360 1.161732354 1.466915814 3.04041448 9.308612938
120 threads
minor-faults 983,466 983,655 983,366 983,372 983,363 984,083 984,164
time, seconds 1.595846553 1.667902182 2.008959376 2.425380942 2.941368804 5.977807890 18.401846125
This patch (of 2):
Introduce new vm_ops callback ->map_pages() and uses it for mapping easy
accessible pages around fault address.
On read page fault, if filesystem provides ->map_pages(), we try to map up
to FAULT_AROUND_PAGES pages around page fault address in hope to reduce
number of minor page faults.
We call ->map_pages first and use ->fault() as fallback if page by the
offset is not ready to be mapped (cold page cache or something).
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Matthew Wilcox <matthew.r.wilcox@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Ning Qu <quning@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-04-08 06:37:18 +08:00
|
|
|
|
mm: close page_mkwrite races
Change page_mkwrite to allow implementations to return with the page
locked, and also change it's callers (in page fault paths) to hold the
lock until the page is marked dirty. This allows the filesystem to have
full control of page dirtying events coming from the VM.
Rather than simply hold the page locked over the page_mkwrite call, we
call page_mkwrite with the page unlocked and allow callers to return with
it locked, so filesystems can avoid LOR conditions with page lock.
The problem with the current scheme is this: a filesystem that wants to
associate some metadata with a page as long as the page is dirty, will
perform this manipulation in its ->page_mkwrite. It currently then must
return with the page unlocked and may not hold any other locks (according
to existing page_mkwrite convention).
In this window, the VM could write out the page, clearing page-dirty. The
filesystem has no good way to detect that a dirty pte is about to be
attached, so it will happily write out the page, at which point, the
filesystem may manipulate the metadata to reflect that the page is no
longer dirty.
It is not always possible to perform the required metadata manipulation in
->set_page_dirty, because that function cannot block or fail. The
filesystem may need to allocate some data structure, for example.
And the VM cannot mark the pte dirty before page_mkwrite, because
page_mkwrite is allowed to fail, so we must not allow any window where the
page could be written to if page_mkwrite does fail.
This solution of holding the page locked over the 3 critical operations
(page_mkwrite, setting the pte dirty, and finally setting the page dirty)
closes out races nicely, preventing page cleaning for writeout being
initiated in that window. This provides the filesystem with a strong
synchronisation against the VM here.
- Sage needs this race closed for ceph filesystem.
- Trond for NFS (http://bugzilla.kernel.org/show_bug.cgi?id=12913).
- I need it for fsblock.
- I suspect other filesystems may need it too (eg. btrfs).
- I have converted buffer.c to the new locking. Even simple block allocation
under dirty pages might be susceptible to i_size changing under partial page
at the end of file (we also have a buffer.c-side problem here, but it cannot
be fixed properly without this patch).
- Other filesystems (eg. NFS, maybe btrfs) will need to change their
page_mkwrite functions themselves.
[ This also moves page_mkwrite another step closer to fault, which should
eventually allow page_mkwrite to be moved into ->fault, and thus avoiding a
filesystem calldown and page lock/unlock cycle in __do_fault. ]
[akpm@linux-foundation.org: fix derefs of NULL ->mapping]
Cc: Sage Weil <sage@newdream.net>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
Signed-off-by: Nick Piggin <npiggin@suse.de>
Cc: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-05-01 06:08:16 +08:00
|
|
|
->page_mkwrite() is called when a previously read-only pte is
|
|
|
|
|
about to become writeable. The filesystem again must ensure that there are
|
|
|
|
|
no truncate/invalidate races, and then return with the page locked. If
|
|
|
|
|
the page has been truncated, the filesystem should not look up a new page
|
|
|
|
|
like the ->fault() handler, but simply return with VM_FAULT_NOPAGE, which
|
|
|
|
|
will cause the VM to retry the fault.
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2015-04-16 07:15:11 +08:00
|
|
|
->pfn_mkwrite() is the same as page_mkwrite but when the pte is
|
|
|
|
|
VM_PFNMAP or VM_MIXEDMAP with a page-less entry. Expected return is
|
|
|
|
|
VM_FAULT_NOPAGE. Or one of the VM_FAULT_ERROR types. The default behavior
|
|
|
|
|
after this call is to make the pte read-write, unless pfn_mkwrite returns
|
|
|
|
|
an error.
|
|
|
|
|
|
2008-07-24 12:27:05 +08:00
|
|
|
->access() is called when get_user_pages() fails in
|
2013-12-06 03:34:05 +08:00
|
|
|
access_process_vm(), typically used to debug a process through
|
2008-07-24 12:27:05 +08:00
|
|
|
/proc/pid/mem or ptrace. This function is needed only for
|
|
|
|
|
VM_IO | VM_PFNMAP VMAs.
|
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
================================================================================
|
|
|
|
|
Dubious stuff
|
|
|
|
|
|
|
|
|
|
(if you break something or notice that it is broken and do not fix it yourself
|
|
|
|
|
- at least put it here)
|
