search for: inode_init_alway

...list() method of the > generix POSIX ACL xattr handlers in their ->listxattr() inode operation. > This is a very limited set of filesystems. For most of them there is no > dependence on the generic POSIX ACL xattr handler in any way. > > In addition, during inode initalization in inode_init_always() the > registered xattr handlers in sb->s_xattr are used to raise IOP_XATTR in > inode->i_opflags. > > With the incoming removal of the legacy POSIX ACL handlers it is at > least possible for a filesystem to only implement POSIX ACLs but no > other xattrs. If that were to...

...on of the new posix acl api last cycle we still left the generic POSIX ACL xattr handler around for two reasons. First, because a few filesystems relied on the ->list() method of the generic POSIX ACL xattr handlers in their ->listxattr() inode operation. Second, during inode initalization in inode_init_always() the registered xattr handlers in sb->s_xattr are used to raise IOP_XATTR in inode->i_opflags. With the removal of the legacy POSIX ACL handlers it is at least possible for a filesystem to only implement POSIX ACLs but no other xattrs. If that were to happen we would miss to raise IOP_XATT...

With the ATI bug I was hitting earlier fixed, only my btrfs partition continues to show high cpu usage for some operations. Rsync, git pull, git checkout and svn up are typicall operations which trigger the high cpu usage. As an example, this perf report is from using git checkout to change to a new branch; the change needed to checkout 208 files out of about 1600 total files. du(1) reports

I did a very quick pass at removing all the non-KMS support from the DDX. It's tested on G80 but nowhere else currently, I thought some discussion would be a good idea rather than just ripping it out :) The non-KMS paths are messy, and lets face it, rotting badly. IMO the KMS code is stable enough now that we can continue without the UMS crutch, and indeed, the KMS code supports a lot more

i_alloc_sem has always been a bit of an odd "lock". It''s the only remaining rw_semaphore that can be released by a different thread than the one that locked it, and it''s use case in the core direct I/O code is more like a counter given that the writers already have external serialization. This series removes it in favour of a simpler counter scheme, thus getting rid

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge

Memory fragmentation introduced by ballooning might reduce significantly the number of 2MB contiguous memory blocks that can be used within a guest, thus imposing performance penalties associated with the reduced number of transparent huge pages that could be used by the guest workload. This patch-set follows the main idea discussed at 2012 LSFMMS session: "Ballooning for transparent huge