handle forget inline instead of in goroutine
when we are under memory pressure, or echo 3 > /proc/sys/vm/drop_caches, kernel can send us many forget ops at the same time if we have lots of inodes in memory. Running them all in goroutines can lead to even more memory usage and eventually OOM.geesefs-0-30-9
parent
fe7f3a55dc
commit
1ab97fb2eb
|
@ -72,8 +72,10 @@ type FileSystem interface {
|
||||||
// method.Respond with the resulting error. Unsupported ops are responded to
|
// method.Respond with the resulting error. Unsupported ops are responded to
|
||||||
// directly with ENOSYS.
|
// directly with ENOSYS.
|
||||||
//
|
//
|
||||||
// Each call to a FileSystem method is made on its own goroutine, and is free
|
// Each call to a FileSystem method (except ForgetInode) is made on
|
||||||
// to block.
|
// its own goroutine, and is free to block. ForgetInode may be called
|
||||||
|
// synchronously, and should not depend on calls to other methods
|
||||||
|
// being received concurrently.
|
||||||
//
|
//
|
||||||
// (It is safe to naively process ops concurrently because the kernel
|
// (It is safe to naively process ops concurrently because the kernel
|
||||||
// guarantees to serialize operations that the user expects to happen in order,
|
// guarantees to serialize operations that the user expects to happen in order,
|
||||||
|
@ -109,7 +111,15 @@ func (s *fileSystemServer) ServeOps(c *fuse.Connection) {
|
||||||
}
|
}
|
||||||
|
|
||||||
s.opsInFlight.Add(1)
|
s.opsInFlight.Add(1)
|
||||||
go s.handleOp(c, ctx, op)
|
if _, ok := op.(*fuseops.ForgetInodeOp); ok {
|
||||||
|
// Special case: call in this goroutine for
|
||||||
|
// forget inode ops, which may come in a
|
||||||
|
// flurry from the kernel and are generally
|
||||||
|
// cheap for the file system to handle
|
||||||
|
s.handleOp(c, ctx, op)
|
||||||
|
} else {
|
||||||
|
go s.handleOp(c, ctx, op)
|
||||||
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue