[PATCH] Docs/mm: document Shared Memory Filesystem

[PATCH] Docs/mm: document Shared Memory Filesystem

[Kit Dallege]

Fill in the shmfs.rst stub created in commit 481cc97349d6
("mm,doc: Add new documentation structure") as part of
the structured memory management documentation following
Mel Gorman's book outline.

Signed-off-by: Kit Dallege <xaum.io@gmail.com>
---
 Documentation/mm/shmfs.rst | 114 +++++++++++++++++++++++++++++++++++++
 1 file changed, 114 insertions(+)

diff --git a/Documentation/mm/shmfs.rst b/Documentation/mm/shmfs.rst
index 8b01ebb4c30e..1dadf9b481ce 100644
--- a/Documentation/mm/shmfs.rst
+++ b/Documentation/mm/shmfs.rst
@@ -3,3 +3,117 @@
 ========================
 Shared Memory Filesystem
 ========================
+
+The shared memory filesystem (tmpfs, also known as shmem) provides an
+in-memory filesystem used for ``/tmp`` mounts, POSIX shared memory
+(``shm_open()``), System V shared memory, and anonymous shared mappings
+created with ``mmap(MAP_SHARED | MAP_ANONYMOUS)``.  The implementation is
+in ``mm/shmem.c``.
+
+.. contents:: :local:
+
+How It Works
+============
+
+tmpfs stores file contents in the page cache using swap as its backing
+store rather than a disk filesystem.  Pages are allocated on demand when
+written to or faulted in.  When the system is under memory pressure, tmpfs
+pages can be swapped out just like anonymous pages.
+
+This design means tmpfs files consume no disk space — their size is bounded
+only by available memory and swap.  It also means tmpfs data does not
+survive a reboot, making it suitable for scratch data that benefits from
+memory-speed access without needing durability.
+
+Each tmpfs inode tracks two key counters: allocated pages (resident in
+memory) and swapped pages (evicted to swap).  These are maintained by
+the ``shmem_charge()`` and ``shmem_uncharge()`` accounting functions,
+which keep the inode's block usage consistent with the filesystem's mount
+limits.
+
+Page Cache Integration
+======================
+
+tmpfs uses the kernel's page cache (xarray) to index its pages by file
+offset.  When a page is read or faulted in, the page cache is checked
+first.  If the page has been swapped out, a swap entry is found in its
+place, and the page is swapped back in transparently.
+
+When a page is added to the cache for a tmpfs file, it replaces any
+existing swap entry at that offset.  When a page is evicted by reclaim,
+a swap entry takes its place.  Shadow entries (see
+Documentation/mm/page_reclaim.rst) may also be stored to support working
+set detection.
+
+Swap Integration
+================
+
+Under memory pressure, the reclaim path can evict tmpfs pages to swap just
+like anonymous pages.  This is transparent to the filesystem — the page
+cache slot simply transitions from holding a folio to holding a swap entry.
+
+When a process accesses a swapped-out tmpfs page, the page fault handler
+reads the swap entry from the page cache, allocates a new page, reads the
+data from swap, and inserts the page back into the cache.  This swap-in
+path is specific to shmem and handles locking between concurrent faults
+on the same page.
+
+Huge Page Support
+=================
+
+tmpfs can allocate transparent huge pages for its files.  The ``huge=``
+mount option controls the policy:
+
+- ``never``: only base pages (default).
+- ``always``: attempt huge page allocation for every new page.
+- ``within_size``: use huge pages only within the file's current size.
+- ``advise``: use huge pages only for mappings with ``MADV_HUGEPAGE``.
+
+When a huge page is allocated but only partially used (e.g., a file is
+smaller than a huge page), memory is wasted.  To mitigate this, tmpfs
+registers a shrinker that identifies huge pages where the file has been
+truncated or punched below the huge page boundary, and splits them back
+into base pages so the unused portion can be reclaimed.
+
+Accounting and Limits
+=====================
+
+Mount Options
+-------------
+
+tmpfs mounts accept ``size=`` and ``nr_inodes=`` options that cap the
+total blocks and inodes in the filesystem.  Every page allocation is
+checked against the block limit; if the limit would be exceeded, the
+allocation fails with ``ENOSPC``.
+
+These limits are enforced in-kernel and apply to all users of the
+filesystem.  They can be changed at remount time.
+
+Quota Support
+-------------
+
+With ``CONFIG_TMPFS_QUOTA``, tmpfs supports user and group quotas.  Each
+allocated block is charged to the owning user/group, and allocations fail
+if the quota is exceeded.  Quota state is stored in memory and does not
+persist across mounts.
+
+Memory Cgroups
+--------------
+
+tmpfs pages are charged to the memory cgroup of the process that
+instantiates them.  This means tmpfs memory counts toward cgroup limits
+and can trigger cgroup-level reclaim.  Swapping a tmpfs page out and back
+in preserves its cgroup association.
+
+fallocate
+=========
+
+tmpfs supports ``fallocate()`` to preallocate space for a file.
+Preallocated pages are allocated and inserted into the page cache
+immediately, guaranteeing that subsequent writes will not fail with
+``ENOSPC``.
+
+``FALLOC_FL_PUNCH_HOLE`` is also supported: it removes pages from a range
+of the file and returns them to the filesystem's free pool.  This is used
+by applications that want to release portions of a tmpfs file without
+truncating it.
-- 
2.53.0

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Jonathan Corbet]

Kit Dallege <xaum.io@gmail.com> writes:

> Fill in the shmfs.rst stub created in commit 481cc97349d6
> ("mm,doc: Add new documentation structure") as part of
> the structured memory management documentation following
> Mel Gorman's book outline.
>
> Signed-off-by: Kit Dallege <xaum.io@gmail.com>
> ---
>  Documentation/mm/shmfs.rst | 114 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 114 insertions(+)

So we definitely appreciate an effort to improve our documentation, but
I have to ask...where did all of this material come from?  Did you write
it yourself?

(Haven't had a chance to read it in depth yet).

Thanks,

jon

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Kit Dallege]

Hi Jon,

The material was written with AI assistance (Claude) and then verified
against the source code in mm/shmem.c. I read through the implementation,
the existing comments, and Mel Gorman's book outline to identify what
should be covered, then used AI to help draft the prose, which I reviewed
and edited.

I'm happy to rework anything that's inaccurate or doesn't meet the bar.
Should I add an Assisted-by tag to the commit?

Thanks,
Kit

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Andrew Morton]

On Sat, 14 Mar 2026 17:02:47 +0100 Kit Dallege <xaum.io@gmail.com> wrote:

> Hi Jon,
> 
> The material was written with AI assistance (Claude) and then verified
> against the source code in mm/shmem.c. I read through the implementation,
> the existing comments, and Mel Gorman's book outline to identify what
> should be covered, then used AI to help draft the prose, which I reviewed
> and edited.

OK, so you're saying that you created the content and used an LLM to
assist in finishing it off?

> I'm happy to rework anything that's inaccurate or doesn't meet the bar.
> Should I add an Assisted-by tag to the commit?

Yes, Assisted-by: is appropriate and useful here.

From a quick scan, this material appears to be helpful and I think it
would be good for us to get this into the tree in some fashion.  Which
will involve asking the relevant MM developers to review each change.

> Mel Gorman's book outline

Well, Mel may have an opinion on this - hopefully you discussed this
with him beforehand.

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Kit Dallege]

Hi Andrew,

Thanks for the positive feedback. I'll add the Assisted-by tag in v2.

To clarify — I used Gorman's book as a reference for understanding the
subsystem structure, not as a source to copy from. The documentation was
written by reading the current source code and verified against it. I
didn't contact Mel beforehand but the book outline was only used to
identify which topics each stub file should cover.

Happy to have the relevant MM developers review each patch. Should I
resend the series with the Assisted-by tags, or wait for further
feedback first?

Thanks,
Kit

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Hugh Dickins]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

On Sat, 14 Mar 2026, Kit Dallege wrote:

> Hi Andrew,
> 
> Thanks for the positive feedback. I'll add the Assisted-by tag in v2.
> 
> To clarify — I used Gorman's book as a reference for understanding the
> subsystem structure, not as a source to copy from. The documentation was
> written by reading the current source code and verified against it. I
> didn't contact Mel beforehand but the book outline was only used to
> identify which topics each stub file should cover.
> 
> Happy to have the relevant MM developers review each patch. Should I
> resend the series with the Assisted-by tags, or wait for further
> feedback first?
> 
> Thanks,
> Kit

And now the negative feedback: thanks, but NAK to this particular patch.

Documentation/mm/shmfs.rst? I hadn't realized that such a file existed.

tmpfs has been known as tmpfs since 2.4.4 (but a few people do still say
shmfs, and I'd agree with them that shmfs would have been a better name).

Please send a patch, either to delete shmfs.rst and its index entry,
or to redirect its readers to

Documentation/filesystems/tmpfs.rst

I haven't looked up the preferred way to redirect in Documentation:
I expect Jon or Claude can assist you with that :-)

Hugh

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[David Hildenbrand (arm)]

On 3/14/26 19:17, Andrew Morton wrote:
> On Sat, 14 Mar 2026 17:02:47 +0100 Kit Dallege <xaum.io@gmail.com> wrote:
> 
>> Hi Jon,
>>
>> The material was written with AI assistance (Claude) and then verified
>> against the source code in mm/shmem.c. I read through the implementation,
>> the existing comments, and Mel Gorman's book outline to identify what
>> should be covered, then used AI to help draft the prose, which I reviewed
>> and edited.
> 
> OK, so you're saying that you created the content and used an LLM to
> assist in finishing it off?
> 
>> I'm happy to rework anything that's inaccurate or doesn't meet the bar.
>> Should I add an Assisted-by tag to the commit?
> 
> Yes, Assisted-by: is appropriate and useful here.
> 
>  From a quick scan, this material appears to be helpful and I think it
> would be good for us to get this into the tree in some fashion.  Which
> will involve asking the relevant MM developers to review each change.

So, someone with an LLM but no proven experience with the code produced 
some doc, and maintainers/developers should dedicate their precious time 
to do the hard work of checking everything?

I'm all for documenting stuff, especially if newcomers start exploring 
that space by contributing small, carefully crafted documentation updates.

It's then a good learning experience for someone that wants to work on 
the code to really have to understand the code in detail, and what is 
actually worth documenting (and what's an implementation detail).

I see 7 doc updates for 7 different MM subsystems in my inbox, including

So naturally, I get skeptical when it comes to "I read through the 
implementation, the existing comments".

-- 
Cheers,

David

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[David Hildenbrand (arm)]

On 3/15/26 20:50, David Hildenbrand (arm) wrote:
> On 3/14/26 19:17, Andrew Morton wrote:
>> On Sat, 14 Mar 2026 17:02:47 +0100 Kit Dallege <xaum.io@gmail.com> wrote:
>>
>>> Hi Jon,
>>>
>>> The material was written with AI assistance (Claude) and then verified
>>> against the source code in mm/shmem.c. I read through the implementation,
>>> the existing comments, and Mel Gorman's book outline to identify what
>>> should be covered, then used AI to help draft the prose, which I reviewed
>>> and edited.
>>
>> OK, so you're saying that you created the content and used an LLM to
>> assist in finishing it off?
>>
>>> I'm happy to rework anything that's inaccurate or doesn't meet the bar.
>>> Should I add an Assisted-by tag to the commit?
>>
>> Yes, Assisted-by: is appropriate and useful here.
>>
>>   From a quick scan, this material appears to be helpful and I think it
>> would be good for us to get this into the tree in some fashion.  Which
>> will involve asking the relevant MM developers to review each change.
> 
> So, someone with an LLM but no proven experience with the code produced
> some doc, and maintainers/developers should dedicate their precious time
> to do the hard work of checking everything?
> 
> I'm all for documenting stuff, especially if newcomers start exploring
> that space by contributing small, carefully crafted documentation updates.
> 
> It's then a good learning experience for someone that wants to work on
> the code to really have to understand the code in detail, and what is
> actually worth documenting (and what's an implementation detail).
> 
> I see 7 doc updates for 7 different MM subsystems in my inbox, including

... "the buddy, and for example, no mentioning of the pcp, but for some 
reason page isolation instead."


-- 
Cheers,

David

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Mike Rapoport]

On Sun, Mar 15, 2026 at 08:50:04PM +0100, David Hildenbrand (arm) wrote:
> On 3/14/26 19:17, Andrew Morton wrote:
> > On Sat, 14 Mar 2026 17:02:47 +0100 Kit Dallege <xaum.io@gmail.com> wrote:
> > 
> > > Hi Jon,
> > > 
> > > The material was written with AI assistance (Claude) and then verified
> > > against the source code in mm/shmem.c. I read through the implementation,
> > > the existing comments, and Mel Gorman's book outline to identify what
> > > should be covered, then used AI to help draft the prose, which I reviewed
> > > and edited.
> > 
> > OK, so you're saying that you created the content and used an LLM to
> > assist in finishing it off?
> > 
> > > I'm happy to rework anything that's inaccurate or doesn't meet the bar.
> > > Should I add an Assisted-by tag to the commit?
> > 
> > Yes, Assisted-by: is appropriate and useful here.
> > 
> >  From a quick scan, this material appears to be helpful and I think it
> > would be good for us to get this into the tree in some fashion.  Which
> > will involve asking the relevant MM developers to review each change.
> 
> So, someone with an LLM but no proven experience with the code produced some
> doc, and maintainers/developers should dedicate their precious time to do
> the hard work of checking everything?
> 
> I'm all for documenting stuff, especially if newcomers start exploring that
> space by contributing small, carefully crafted documentation updates.
> 
> It's then a good learning experience for someone that wants to work on the
> code to really have to understand the code in detail, and what is actually
> worth documenting (and what's an implementation detail).
> 
> I see 7 doc updates for 7 different MM subsystems in my inbox, including

Heh, it's wider:
https://lore.kernel.org/all/?q=Kit+Dallege

> So naturally, I get skeptical when it comes to "I read through the
> implementation, the existing comments".

I skimmed through bootmem doc, it's, well, inaccurate. And with tens of
documentation patches at the same day, I really doubt there was enough
effort to understand the code. 
 
> -- 
> Cheers,
> David

-- 
Sincerely yours,
Mike.

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Lorenzo Stoakes (Oracle)]

NAK to this and every patch like this.

On Sat, Mar 14, 2026 at 11:17:57AM -0700, Andrew Morton wrote:
> On Sat, 14 Mar 2026 17:02:47 +0100 Kit Dallege <xaum.io@gmail.com> wrote:
>
> > Hi Jon,
> >
> > The material was written with AI assistance (Claude) and then verified
> > against the source code in mm/shmem.c. I read through the implementation,
> > the existing comments, and Mel Gorman's book outline to identify what
> > should be covered, then used AI to help draft the prose, which I reviewed
> > and edited.

'The material was written with AI assistance'

That reads to me like Claude generated this and you 'checked' it, but
absolutely none of the commit messages give the slightest indication that
you understand any of it.

In fact they're all useless, lazy and seem auto-generated too.

You have no previous contributions to the kernel whatosever, let alone in
mm.

So you are not well placed honestly to check any of this, and are instead
putting in low effoft and expecting finite maintainer resource to review
this for you.

NO to this.

I can go right now and get Claude to do the same thing, this is not
helpful.

>
> OK, so you're saying that you created the content and used an LLM to
> assist in finishing it off?

See above, that is not what it reads like.

>
> > I'm happy to rework anything that's inaccurate or doesn't meet the bar.
> > Should I add an Assisted-by tag to the commit?
>
> Yes, Assisted-by: is appropriate and useful here.

https://kernel.org/doc/html/latest/process/generated-content.html

"As with the output of any tooling, the result may be incorrect or
inappropriate. You are expected to understand and to be able to defend
everything you submit. If you are unable to do so, then do not submit the
resulting changes.

If you do so anyway, maintainers are entitled to reject your series without
detailed review."

>
> >From a quick scan, this material appears to be helpful and I think it
> would be good for us to get this into the tree in some fashion.  Which
> will involve asking the relevant MM developers to review each change.

It's not useful, it is doing something anybody could do, and delegates all
the work to the sub-maintainers, and there's already too much review in mm.

I do NOT want this precedent set.

>
> > Mel Gorman's book outline
>
> Well, Mel may have an opinion on this - hopefully you discussed this
> with him beforehand.

Mel's book is fantastic and Mel is great but it's very old now.

In any case I question whether even this has been done, look at the commit
messages. They're as lazy as they could be and look auto-generated.

Kit - if this is sincere, please take the time to try to understand what
you're describing FIRST, in DEPTH.

In fact I don't think it makes any sense for us to take doc patches about
mm from anybody other than somebody with actual experience working in mm or
who can SERIOUSLY demonstrate understanding.

Thanks, Lorenzo

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Mike Rapoport]

On Sun, Mar 15, 2026 at 10:00:00PM +0200, Mike Rapoport wrote:
> On Sun, Mar 15, 2026 at 08:50:04PM +0100, David Hildenbrand (arm) wrote:
> > On 3/14/26 19:17, Andrew Morton wrote:
> > > On Sat, 14 Mar 2026 17:02:47 +0100 Kit Dallege <xaum.io@gmail.com> wrote:
> > > 
> > > > Hi Jon,
> > > > 
> > > > The material was written with AI assistance (Claude) and then verified
> > > > against the source code in mm/shmem.c. I read through the implementation,
> > > > the existing comments, and Mel Gorman's book outline to identify what
> > > > should be covered, then used AI to help draft the prose, which I reviewed
> > > > and edited.
> > > 
> > > OK, so you're saying that you created the content and used an LLM to
> > > assist in finishing it off?
> > > 
> > > > I'm happy to rework anything that's inaccurate or doesn't meet the bar.
> > > > Should I add an Assisted-by tag to the commit?
> > > 
> > > Yes, Assisted-by: is appropriate and useful here.
> > > 
> > >  From a quick scan, this material appears to be helpful and I think it
> > > would be good for us to get this into the tree in some fashion.  Which
> > > will involve asking the relevant MM developers to review each change.
> > 
> > So, someone with an LLM but no proven experience with the code produced some
> > doc, and maintainers/developers should dedicate their precious time to do
> > the hard work of checking everything?
> 
> > I'm all for documenting stuff, especially if newcomers start exploring that
> > space by contributing small, carefully crafted documentation updates.
> > 
> > It's then a good learning experience for someone that wants to work on the
> > code to really have to understand the code in detail, and what is actually
> > worth documenting (and what's an implementation detail).
> > 
> > I see 7 doc updates for 7 different MM subsystems in my inbox, including
> 
> Heh, it's wider:
> https://lore.kernel.org/all/?q=Kit+Dallege
> 
> > So naturally, I get skeptical when it comes to "I read through the
> > implementation, the existing comments".

And another LLM says there are mistakes:
https://sashiko.dev/#/patchset/20260314152538.100593-1-xaum.io%40gmail.com

-- 
Sincerely yours,
Mike.

Re: [PATCH] Docs/mm: document Shared Memory Filesystem

[Lorenzo Stoakes (Oracle)]

NAK.

The degree of laziness here is really telling, so yet again I'm sorry I don't
believe you've put much effort into this.

You've not bothered cc'ing the right people, you didn't bother with anythign
other than a cookie-cutter commit message, there's a bunch of issues with the
docs even at a cursary glance.

On Sat, Mar 14, 2026 at 04:25:38PM +0100, Kit Dallege wrote:
> Fill in the shmfs.rst stub created in commit 481cc97349d6
> ("mm,doc: Add new documentation structure") as part of
> the structured memory management documentation following
> Mel Gorman's book outline.

>
> Signed-off-by: Kit Dallege <xaum.io@gmail.com>

NAK.

> ---
>  Documentation/mm/shmfs.rst | 114 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 114 insertions(+)
>
> diff --git a/Documentation/mm/shmfs.rst b/Documentation/mm/shmfs.rst
> index 8b01ebb4c30e..1dadf9b481ce 100644
> --- a/Documentation/mm/shmfs.rst
> +++ b/Documentation/mm/shmfs.rst
> @@ -3,3 +3,117 @@
>  ========================
>  Shared Memory Filesystem
>  ========================
> +
> +The shared memory filesystem (tmpfs, also known as shmem) provides an
> +in-memory filesystem used for ``/tmp`` mounts, POSIX shared memory
> +(``shm_open()``), System V shared memory, and anonymous shared mappings
> +created with ``mmap(MAP_SHARED | MAP_ANONYMOUS)``.  The implementation is
> +in ``mm/shmem.c``.

This is already wrong.

> +
> +.. contents:: :local:
> +
> +How It Works
> +============
> +
> +tmpfs stores file contents in the page cache using swap as its backing
> +store rather than a disk filesystem.  Pages are allocated on demand when
> +written to or faulted in.  When the system is under memory pressure, tmpfs
> +pages can be swapped out just like anonymous pages.

What is a 'backing store' what is a 'disk filesystem', 'written to or faulted
in' is wrong, etc.

I won't go on.

This would become 'development by review' and you'd take up HOURS of our time
while we do the actual work.

This isn't how contributions are supposed to work.

> +
> +This design means tmpfs files consume no disk space — their size is bounded
> +only by available memory and swap.  It also means tmpfs data does not
> +survive a reboot, making it suitable for scratch data that benefits from
> +memory-speed access without needing durability.
> +
> +Each tmpfs inode tracks two key counters: allocated pages (resident in
> +memory) and swapped pages (evicted to swap).  These are maintained by
> +the ``shmem_charge()`` and ``shmem_uncharge()`` accounting functions,
> +which keep the inode's block usage consistent with the filesystem's mount
> +limits.
> +
> +Page Cache Integration
> +======================
> +
> +tmpfs uses the kernel's page cache (xarray) to index its pages by file
> +offset.  When a page is read or faulted in, the page cache is checked
> +first.  If the page has been swapped out, a swap entry is found in its
> +place, and the page is swapped back in transparently.
> +
> +When a page is added to the cache for a tmpfs file, it replaces any
> +existing swap entry at that offset.  When a page is evicted by reclaim,
> +a swap entry takes its place.  Shadow entries (see
> +Documentation/mm/page_reclaim.rst) may also be stored to support working
> +set detection.
> +
> +Swap Integration
> +================
> +
> +Under memory pressure, the reclaim path can evict tmpfs pages to swap just
> +like anonymous pages.  This is transparent to the filesystem — the page
> +cache slot simply transitions from holding a folio to holding a swap entry.
> +
> +When a process accesses a swapped-out tmpfs page, the page fault handler
> +reads the swap entry from the page cache, allocates a new page, reads the
> +data from swap, and inserts the page back into the cache.  This swap-in
> +path is specific to shmem and handles locking between concurrent faults
> +on the same page.
> +
> +Huge Page Support
> +=================
> +
> +tmpfs can allocate transparent huge pages for its files.  The ``huge=``
> +mount option controls the policy:
> +
> +- ``never``: only base pages (default).
> +- ``always``: attempt huge page allocation for every new page.
> +- ``within_size``: use huge pages only within the file's current size.
> +- ``advise``: use huge pages only for mappings with ``MADV_HUGEPAGE``.
> +
> +When a huge page is allocated but only partially used (e.g., a file is
> +smaller than a huge page), memory is wasted.  To mitigate this, tmpfs
> +registers a shrinker that identifies huge pages where the file has been
> +truncated or punched below the huge page boundary, and splits them back
> +into base pages so the unused portion can be reclaimed.
> +
> +Accounting and Limits
> +=====================
> +
> +Mount Options
> +-------------
> +
> +tmpfs mounts accept ``size=`` and ``nr_inodes=`` options that cap the
> +total blocks and inodes in the filesystem.  Every page allocation is
> +checked against the block limit; if the limit would be exceeded, the
> +allocation fails with ``ENOSPC``.
> +
> +These limits are enforced in-kernel and apply to all users of the
> +filesystem.  They can be changed at remount time.
> +
> +Quota Support
> +-------------
> +
> +With ``CONFIG_TMPFS_QUOTA``, tmpfs supports user and group quotas.  Each
> +allocated block is charged to the owning user/group, and allocations fail
> +if the quota is exceeded.  Quota state is stored in memory and does not
> +persist across mounts.
> +
> +Memory Cgroups
> +--------------
> +
> +tmpfs pages are charged to the memory cgroup of the process that
> +instantiates them.  This means tmpfs memory counts toward cgroup limits
> +and can trigger cgroup-level reclaim.  Swapping a tmpfs page out and back
> +in preserves its cgroup association.
> +
> +fallocate
> +=========
> +
> +tmpfs supports ``fallocate()`` to preallocate space for a file.
> +Preallocated pages are allocated and inserted into the page cache
> +immediately, guaranteeing that subsequent writes will not fail with
> +``ENOSPC``.
> +
> +``FALLOC_FL_PUNCH_HOLE`` is also supported: it removes pages from a range
> +of the file and returns them to the filesystem's free pool.  This is used
> +by applications that want to release portions of a tmpfs file without
> +truncating it.
> --
> 2.53.0
>
>
>