linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Radosław Smogura" <mail@smogura.eu>
To: Andi Kleen <andi@firstfloor.org>
Cc: linux-mm@kvack.org, "Andrea Arcangeli" <aarcange@redhat.com>,
	"Radosław Smogura" <mail@smogura.eu>
Subject: Re: Hugepages for shm page cache (defrag)
Date: Sun, 7 Aug 2011 19:03:49 +0200	[thread overview]
Message-ID: <201108071903.49700.mail@smogura.eu> (raw)
In-Reply-To: <m2pqlmy7z8.fsf@firstfloor.org>

[-- Attachment #1: Type: Text/Plain, Size: 2382 bytes --]

Andi Kleen <andi@firstfloor.org> Thursday 07 of July 2011 07:28:59
> Radosław Smogura <mail@smogura.eu> writes:
> > Hello,
> > 
> > This is may first try with Linux patch, so please do not blame me too
> > much. Actually I started with small idea to add MAP_HUGTLB for /dev/shm
> > but it grew up in something more like support for huge pages in page
> > cache, but according to documentation to submit alpha-work too, I
> > decided to send this.
> 
> Shouldn't this be rather integrated with the normal transparent huge
> pages? It seems odd to develop parallel infrastructure.
> 
> -Andi
Hello,

I send as attachment some preview of work, last time I putted many work to 
make code less messy, etc, but it is still messy and in alpha stage.

=== Info about changes and how it's works ===
Current work is focused to give support for huge pages for tmpfs, but I 
designed it for private mappings too (my dream will be if I will be able to 
map execution portions of glibc as huge). I think there will be no big change 
to expose THP for general file system.

I putted some effort to do not create new type of huge pages, so I do not use 
longer special flag for managing this.

PMD is establish (from historical reasons) from pte fault, so I unmaps pte's 
from pmd (I think I have memory leak here).

Splitting of huge page for page cache still need some work, and it has 
different concept. Mainly I use currently compound_lock to prohibit concurrent 
splitting etc. Splitting acquires compound lock, then unmaps all pmds, and 
split occurs.

In splitting there is usage of new ref-counting. I may be wrong, but in other 
cases we will need to manage ref-count bit for compound pages (this what is 
included /mm.h, swap.c/ is slightly different from my previous send; I still 
think if I should use irqsave lock for compounds). I think included construct 
removes all "under us" risks.

I don't want to waste Your time for reviewing this work, but I will be glad if 
you will find some time. One thing I worried is about pde locking is it needed 
to do pmd locking, like for pte (or any other kind of locking? I have some 
ideas)?

I hope this time here is no missing files.
Regards,
Radosław Smogura
P. S. In one of mails in CC there is putted wrongly my e-mail address and 
name, please remove it to avoid unknown recipient.

[-- Attachment #2: defrag-preview-20110807.patch.gz --]
[-- Type: application/x-gzip, Size: 20948 bytes --]

      parent reply	other threads:[~2011-08-07 17:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-06 19:31 Hugepages for shm page cache (defrag) Radosław Smogura
2011-07-07  5:28 ` Andi Kleen
2011-07-07 12:02   ` mail
2011-07-08  0:07     ` Hugh Dickins
2011-07-14 20:15       ` mail
2011-07-15 19:50         ` Hugh Dickins
2011-07-30 16:15           ` [PATCH] Changes how ref-count of compound pages are managed Radosław Smogura
2011-08-07 17:03   ` Radosław Smogura [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201108071903.49700.mail@smogura.eu \
    --to=mail@smogura.eu \
    --cc=aarcange@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).