[LSF/MM ATTEND] Btrfs, GFP flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'd like to attend LSF/MM this year. I'm involved in btrfs development
for 5 years and one of the maintainers since early 2015.

* Filesystems

There are topics I'd like to discuss with other btrfs developers as this
would be more interactive than the mail discussions. Hopefully this will
cover things that never make it to the mails. As an example, the direction
of the development, taming the patch flow and other maintainer pleasures.

* FS/MM

I'd like to participate in the discussions about refining the GFP flags
and memory error handling in btrfs in general. It's not a secret that
the current implementation is not robust. I've started with the low-hanging
fruit for 4.5, getting rid of GFP_NOFS in the easy cases. The core work
is still left untouched as this requires identifying all the paths/contexts
that might recurse back to the filesystem.

So far I was able to narrow down a few classes based on the expected
object lifetime and possible IO involved. Namely for the short-lived
allocations (eg. btrfs_path that's used for search & modify the metadata
in the b-tree) it's crucial in many places not to fail. Here I'm thinking
about some emergency reserves that would kick in if the slab/kmalloc
allocation fails. That would be even after a GFP_HIGH fails so it's
expected to be very rare and used at limited number of call sites. This
could be potentially made a more generic part of the allocator.

* MM, debugging helpers

During the analysis I wanted to track per call-site allocation stats (count,
size), and wrote basic version, stats exported via debugfs.

Next to that is a desire for a better fault injection framework, eg. when I
want to exercise a specific call path.  Though I can implement it myself as
needed, I assume that such extension of the existing code could be useful to
others.

(This could be considered marginal and not appropriate for the conference,
but I feel I should mention it as a followup to the previous paragraph.)
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux