From: "Radosław Smogura" <mail@smogura.eu>
To: linux-mm@kvack.org
Cc: Yongqiang Yang <xiaoqiangnk@gmail.com>,
mail@smogura.eu, linux-ext4@vger.kernel.org
Subject: [WIP 18/18] [WIP] Dummy patch for details
Date: Thu, 16 Feb 2012 15:47:57 +0100 [thread overview]
Message-ID: <1329403677-25629-8-git-send-email-mail@smogura.eu> (raw)
In-Reply-To: <1329403677-25629-1-git-send-email-mail@smogura.eu>
I send this dummy patch to describe a bit of work, maybe someone may
have additional ideas, concepts and tips. In any case I'm glad I mapped huge
EXT4 and data was synced to disk.
Some concepts about compounds:
- first_page moved to lru union to free place for buffers
- refcounting changed - compound pages are "auto managed",
page recovering is for backward
compatibilit with 2.6 kernels, actully those kernels allowed
getting tail page of count 0, but at eye glance moving few
times around 0 could cause dangling pointer bug
Compound view.
In distinction to huge pages and THP, file system
compound pages are really loosely treated, as a main difference there is no
implication huge page => huge pmd, huge page may exist and may have no
huge mappings at all.
Each page is managed almost like stand alone, have own count, mapcount, dirty
bit etc. It can't be added to any LRU nor list, because list_head is
shared with compound metadata.
Read / write locking of compound.
Splitting may be dequeued this is to prevent deadlocks, "legacy" code
will probably start with normal page locked, and then try to lock
compound, for splitting purposes this may cause deadlocks (actually this
flag was not included in faulting and enywhere else, but should be).
Still there is no defragmentation daemon nor anything simillar, this
behaviour is forced by MAP_HUGETLB.
Things not made:
* kswapd & co. not tested.
* mlock not fixed, fix will cover get_user_pages & follow_user_pages.
* fork, page_mkclean, mlock, not fixed.
* dropping caches = bug.
* migration not checked
* shmfs - writeback for reclaim should split, simple to make, but ext4
experiments should go first (syncing)
* no huge COW mapping allowed.
* code cleaning from all printk...
Signed-off-by: Radosław Smogura <mail@smogura.eu>
---
mm/filemap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/filemap.c b/mm/filemap.c
index f050209..7174fff 100644
--- a/mm/filemap.c
+++ b/mm/filemap.c
@@ -1783,7 +1783,7 @@ int filemap_fault_huge(struct vm_area_struct *vma, struct vm_fault *vmf)
int ret = VM_FAULT_LOCKED;
error = vma->vm_ops->fault(vma, vmf);
- /* XXX Repeatable flags in __do fault etc. */
+ /* XXX Repeatable flags in __do fault etc. */
if (error & (VM_FAULT_ERROR | VM_FAULT_NOPAGE
| VM_FAULT_RETRY | VM_FAULT_NOHUGE)) {
return error;
--
1.7.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2012-02-16 14:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-16 14:47 [WIP 11/18] Basic support (faulting) for huge pages for shmfs Radosław Smogura
2012-02-16 14:47 ` [WIP 12/18] Additional macros for pmd operations Radosław Smogura
2012-02-16 14:47 ` [WIP 13/18] Zapping and freeing huge mappings Radosław Smogura
2012-02-16 14:47 ` [WIP 14/18] Fixes for proc memory Radosław Smogura
2012-02-16 14:47 ` [WIP 15/18] Splitting and truncating Radosław Smogura
2012-02-16 14:47 ` [WIP 16/18] SHM: Support for splitting on truncation Radosław Smogura
2012-02-16 14:47 ` [WIP 17/18] [Experimental] Support for huge pages in EXT 4 Radosław Smogura
2012-02-16 14:47 ` Radosław Smogura [this message]
2012-02-16 23:42 ` [WIP 11/18] Basic support (faulting) for huge pages for shmfs Ted Ts'o
2012-02-17 14:12 ` Radosław Smogura
2012-02-17 14:41 ` Ted Ts'o
2012-02-17 14:51 ` Radosław Smogura
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=1329403677-25629-8-git-send-email-mail@smogura.eu \
--to=mail@smogura.eu \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=xiaoqiangnk@gmail.com \
/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).