[RFC] Reclaiming PG_private

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

 



We're perenially short of page flags, and I don't really see the need
for PG_private to exist.  We have 32/64 bits available in page->private,
and we don't seem to need the extra bit.

Most users store a pointer in page->private, and so PagePrivate() being
implemented as page->private != 0 is appropriate.

Some users simply SetPagePrivate() and don't touch page->private.
Those users could instead set page->private to 1.

Do we have any users which want to SetPagePrivate() and want to put a
meaningful zero value in page->private?

AFS stores a pair of integers in page->private, but the second integer
must be greater than the first one, so they can't both be zero.  btrfs
stores a real or fake pointer.  buffer_head filesystems generally store
a buffer_head pointer.  fscrypt stores a pointer.  erofs stores a real or
fake pointer.  f2fs does set PagePrivate and also set the pointer to NULL,
but it's not clear whether that's intentional.  iomap stores a pointer.
jfs stores a pointer.  nfs stores a pointer.  ntfs stores a pointer.
orangefs stores a pointer.

So ... what's going on with f2fs?  Does it need to distinguish between
a page which has f2fs_set_page_private(page, 0) called on it, and a page
which has had f2fs_clear_page_private() called on it?



[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