linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Hirokazu Takahashi <taka@valinux.co.jp>
To: marcelo.tosatti@cyclades.com
Cc: iwamoto@valinux.co.jp, haveblue@us.ibm.com, linux-mm@kvack.org
Subject: Re: [RFC] memory defragmentation to satisfy high order allocations
Date: Wed, 13 Oct 2004 02:55:23 +0900 (JST)	[thread overview]
Message-ID: <20041013.025523.74732789.taka@valinux.co.jp> (raw)
In-Reply-To: <20041012103500.GA3168@logos.cnet>

Hi,

> It will be much faster and not interfere with swap space.
> 
> I'll use one bit of "swap type" to identify such "migration pte's".
>
> I'll test it with memory migration operation first then with 
> memory defragmentation.
> 
> Hope it works fine.

IMHO, if one "swap type" is reserved for it, a target page can be
inserted in swapper_space directly. I guess it may be possible to
reuse the swapper_space and some of the existing codes, which should
be moved out of #ifdef CONFIG_SWAP though.

> struct idr migration_idr;
> struct address_space migration_space = {
>         .page_tree      = RADIX_TREE_INIT(GFP_ATOMIC),
>         .tree_lock      = RW_LOCK_UNLOCKED,
>         .a_ops          = NULL,
>         .flags          = GFP_HIGHUSER,
>         .i_mmap_nonlinear = LIST_HEAD_INIT(migration_space.i_mmap_nonlinear),
>         .backing_dev_info = NULL,
> };
> 
> int init_migration_cache(void) 
> {
> 	idr_init(&migration_idr);
> 
> 	printk(KERN_INFO "Initializating migration cache!\n");
> 
> }
> 
> __initcall(init_migration_cache);
> 
> struct page *lookup_migration_cache(int id) { 
> 	return find_get_page(&migration_space, id);
> }
> 
> int remove_from_migration_cache(struct page *page, int id)
> {
> 	write_lock_irq(&migration_space.tree_lock);
>         idr_remove(&migration_idr, id);
> 	radix_tree_delete(&migration_space.page_tree, id);
> 	write_unlock_irq(&migration_space.tree_lock);
> }
> 
> int add_to_migration_cache(struct page *page) 
> {
> 	int error, offset;
> 	int gfp_mask = GFP_KERNEL;
> 
> 	BUG_ON(PageSwapCache(page));
> 	BUG_ON(PagePrivate(page));
> 
>         if (idr_pre_get(&migration_idr, GFP_ATOMIC) == 0)
>                 return -ENOMEM;

I guess GFP_KERNEL is enough.

> 	error = radix_tree_preload(gfp_mask);
> 
> 	if (!error) {
> 		write_lock_irq(&migration_space.tree_lock);
> 	        error = idr_get_new(&migration_idr, NULL, &offset);
> 
> 		error = radix_tree_insert(&migration_space.page_tree, offset,
> 							page);
> 
> 		if (!error) {
> 			page_cache_get(page);
> 			SetPageLocked(page);
> 			page->private = offset;
> 			page->mapping = &migration_space;
> 		}
> 		write_unlock_irq(&migration_cache.tree_lock);
>                 radix_tree_preload_end();
> 
> 	}
> 
> 	return error;
> }
> 
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2004-10-12 17:55 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-01 18:22 Marcelo Tosatti
2004-10-01 20:11 ` Andrew Morton
2004-10-01 19:04   ` Marcelo Tosatti
2004-10-01 21:00     ` Andrew Morton
2004-10-01 21:57     ` Dave Hansen
2004-10-01 23:42       ` Marcelo Tosatti
2004-10-02  1:17         ` Andrew Morton
2004-10-02  9:30         ` Hirokazu Takahashi
2004-10-02 18:33           ` Marcelo Tosatti
2004-10-03  4:13             ` Hirokazu Takahashi
2004-10-03 14:07               ` Marcelo Tosatti
2004-10-03 18:35                 ` Hirokazu Takahashi
2004-10-03 19:21                   ` Trond Myklebust
2004-10-03 20:03                     ` Hirokazu Takahashi
2004-10-03 20:44                       ` Trond Myklebust
2004-10-04 13:02                         ` Hirokazu Takahashi
2004-10-04 17:24                   ` Marcelo Tosatti
2004-10-05  2:53                     ` Hirokazu Takahashi
2004-10-07 12:06                       ` Marcelo Tosatti
2004-10-08  7:00                         ` Hirokazu Takahashi
2004-10-08 10:00                           ` Marcelo Tosatti
2004-10-08 12:23                             ` Hirokazu Takahashi
2004-10-08 12:41                               ` Marcelo Tosatti
2004-10-08 16:52                                 ` Hirokazu Takahashi
2004-10-08 15:36                                   ` Marcelo Tosatti
2004-10-12 10:56                                     ` IWAMOTO Toshihiro
2004-10-12 10:35                                       ` Marcelo Tosatti
2004-10-12 17:55                                         ` Hirokazu Takahashi [this message]
2004-10-12 14:26                                       ` Martin J. Bligh
2004-10-12 12:17                                         ` Marcelo Tosatti
2004-10-12 15:01                                         ` Dave Hansen
2004-10-04  3:24                 ` IWAMOTO Toshihiro
2004-10-04  2:22               ` Dave Hansen
2004-10-05 16:46               ` [PATCH] mhp: transfer dirty tag at radix_tree_replace Marcelo Tosatti
2004-10-05 18:35                 ` Dave Hansen
2004-10-06  7:39                 ` Hirokazu Takahashi
2004-10-08  8:15                   ` Hirokazu Takahashi
2004-10-08 20:36                     ` Marcelo Tosatti
2004-10-04  4:09             ` [RFC] memory defragmentation to satisfy high order allocations IWAMOTO Toshihiro
2004-10-04 17:29               ` Marcelo Tosatti
2004-10-02  2:30 ` Nick Piggin
2004-10-02  3:08   ` Marcelo Tosatti
2004-10-04  8:15     ` Nick Piggin
2004-10-02  2:41 ` Nick Piggin
2004-10-02  3:50   ` Hirokazu Takahashi
2004-10-02 16:06   ` Marcelo Tosatti
2004-10-04  2:38 ` Hiroyuki KAMEZAWA
2004-10-04 17:32   ` Marcelo Tosatti
2004-10-04  6:58 ` Hiroyuki KAMEZAWA
2004-10-07 15:58   ` memory hotplug and mem= Marcelo Tosatti
2004-10-07 18:36     ` Dave Hansen
2004-10-07 17:01       ` Marcelo Tosatti
2004-10-07 19:10         ` Dave Hansen
2004-10-07 20:25         ` Dave Hansen
2004-10-11 16:40 [RFC] memory defragmentation to satisfy high order allocations linux

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=20041013.025523.74732789.taka@valinux.co.jp \
    --to=taka@valinux.co.jp \
    --cc=haveblue@us.ibm.com \
    --cc=iwamoto@valinux.co.jp \
    --cc=linux-mm@kvack.org \
    --cc=marcelo.tosatti@cyclades.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