headers
Dave Hansen | 1 Jul 2004 01:31
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

On Wed, 2004-06-30 at 04:17, IWAMOTO Toshihiro wrote:
> Hi,
> 
> this is an updated version of my memory hotremoval patch.
> I'll only include the main patch which contains page remapping code.
> The other two files, which haven't changed much from April, can be
> found at http://people.valinux.co.jp/~iwamoto/mh.html .

I tried your code and it oopsed pretty fast:

NUMA - single node, flat memory mode, but broken in several blocks
Rounding down maxpfn 950265 -> 949248
node 0 start 0
node 1 start 65536
node 2 start 131072
node 3 start 196608
node 4 start 262144
node 5 start 327680
node 6 start 393216
node 7 start 458752
physnode_map 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Warning only 1920MB will be used.
Use a HIGHMEM enabled kernel.
1892MB LOWMEM available.
min_low_pfn = 1080, max_low_pfn = 484352, highstart_pfn = 0
Low memory ends at vaddr f6400000
node 0 will remap to vaddr f6400000 -
High memory starts at vaddr 80000000
found SMP MP-table at 0009e1d0
On node 0 totalpages: 65536
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Hansen | 1 Jul 2004 02:11
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

On Wed, 2004-06-30 at 04:17, IWAMOTO Toshihiro wrote:
> Due to struct page changes, page->mapping == NULL predicate can no
> longer be used for detecting cancellation of an anonymous page
> remapping operation.  So the PG_again bit is being used again.
> It may be still possible to kill the PG_again bit, but the priority is
> rather low.

But, you reintroduced it everywhere, including file-backed pages, not
just for anonymous pages?  Why was this necessary?

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
IWAMOTO Toshihiro | 1 Jul 2004 04:10
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

At Wed, 30 Jun 2004 16:31:12 -0700,
Dave Hansen wrote:
> 
> On Wed, 2004-06-30 at 04:17, IWAMOTO Toshihiro wrote:
> > Hi,
> > 
> > this is an updated version of my memory hotremoval patch.
> > I'll only include the main patch which contains page remapping code.
> > The other two files, which haven't changed much from April, can be
> > found at http://people.valinux.co.jp/~iwamoto/mh.html .
> 
> I tried your code and it oopsed pretty fast:

This is because I forgot to update rotate.sh in my web page last night.
I've updated the file, please download and try again.

It is also necessary to issue several "plug" commands before running
rotate.sh.

	# echo plug 1 > /proc/memhotplug
	# echo plug 2 > /proc/memhotplug
	...

> physnode_map 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
> Warning only 1920MB will be used.
> Use a HIGHMEM enabled kernel.
> 1892MB LOWMEM available.

Did you use 2G/2G split? That config should work too, but I usually
test with CONFIG_HIGHMEM4G and CONFIG_MEMHOTPLUG_BLKSIZE=512.
(Continue reading)

Permalink | Reply | 0 comments |
headers
IWAMOTO Toshihiro | 1 Jul 2004 05:05
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

At Wed, 30 Jun 2004 17:11:11 -0700,
Dave Hansen wrote:
> 
> On Wed, 2004-06-30 at 04:17, IWAMOTO Toshihiro wrote:
> > Due to struct page changes, page->mapping == NULL predicate can no
> > longer be used for detecting cancellation of an anonymous page
> > remapping operation.  So the PG_again bit is being used again.
> > It may be still possible to kill the PG_again bit, but the priority is
> > rather low.
> 
> But, you reintroduced it everywhere, including file-backed pages, not
> just for anonymous pages?  Why was this necessary?

Which PG_again check are you talking about?
I think BUG_ON()s in file backed page codes should be kept for now.

For swap pages, one possibility to reserve a special swap entry
constant (SWAP_AGAIN) and check page->private instead of PageAgain
check, but I'm not sure if this is a good idea.

#define	SWAP_AGAIN	~0UL

...

static int do_swap_page(struct mm_struct * mm,
        struct vm_area_struct * vma, unsigned long address,
        pte_t *page_table, pmd_t *pmd, pte_t orig_pte, int write_access)
{
...
again:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Hansen | 1 Jul 2004 07:28
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

On Wed, 2004-06-30 at 20:05, IWAMOTO Toshihiro wrote:
> At Wed, 30 Jun 2004 17:11:11 -0700,
> Dave Hansen wrote:
> > 
> > On Wed, 2004-06-30 at 04:17, IWAMOTO Toshihiro wrote:
> > > Due to struct page changes, page->mapping == NULL predicate can no
> > > longer be used for detecting cancellation of an anonymous page
> > > remapping operation.  So the PG_again bit is being used again.
> > > It may be still possible to kill the PG_again bit, but the priority is
> > > rather low.
> > 
> > But, you reintroduced it everywhere, including file-backed pages, not
> > just for anonymous pages?  Why was this necessary?
> 
> Which PG_again check are you talking about?
> I think BUG_ON()s in file backed page codes should be kept for now.

I'm referring to all of the code segments like this:

        +       if (PageAgain(page)) {
        +               unlock_page(page);
        +               page_cache_release(page);
        +               goto again;
        +       }
        +       BUG_ON(PageAgain(page));

For any page that's in the page cache that you want to remove, simply
take the page lock, overwrite page->mapping, and the page cache code
will take care of the rest, no PG_again needed.
(Continue reading)

Permalink | Reply | 0 comments |
headers
IWAMOTO Toshihiro | 1 Jul 2004 07:58
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

At Wed, 30 Jun 2004 22:28:44 -0700,
Dave Hansen wrote:
> 
> On Wed, 2004-06-30 at 20:05, IWAMOTO Toshihiro wrote:
> > At Wed, 30 Jun 2004 17:11:11 -0700,
> > Dave Hansen wrote:
> > > 
> > > On Wed, 2004-06-30 at 04:17, IWAMOTO Toshihiro wrote:
> > > > Due to struct page changes, page->mapping == NULL predicate can no
> > > > longer be used for detecting cancellation of an anonymous page
> > > > remapping operation.  So the PG_again bit is being used again.
> > > > It may be still possible to kill the PG_again bit, but the priority is
> > > > rather low.
> > > 
> > > But, you reintroduced it everywhere, including file-backed pages, not
> > > just for anonymous pages?  Why was this necessary?
> > 
> > Which PG_again check are you talking about?
> > I think BUG_ON()s in file backed page codes should be kept for now.
> 
> I'm referring to all of the code segments like this:
>         
>         +       if (PageAgain(page)) {
>         +               unlock_page(page);
>         +               page_cache_release(page);
>         +               goto again;
>         +       }
>         +       BUG_ON(PageAgain(page));

Such code only appears only in try_to_unuse and do_swap_page.  These
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dave Hansen | 1 Jul 2004 08:15
Picon
Favicon

Re: [Lhms-devel] new memory hotremoval patch

On Wed, 2004-06-30 at 22:58, IWAMOTO Toshihiro wrote:
> Such code only appears only in try_to_unuse and do_swap_page.  These
> functions aren't for page caches.
> 
> I'm confused.  Weren't you talking about page cache code?

Ahh.  Gotcha.  MI saw some of the BUG_ON()s and some of the swap code
and misinterpreted where the flag was being used.  

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>
Permalink | Reply | 0 comments |
headers
Hirokazu Takahashi | 1 Jul 2004 09:16
Picon
Favicon
Gravatar

[patch] new memory hotremoval patch for hugetlbpages

Hello, 

> this is an updated version of my memory hotremoval patch.
> I'll only include the main patch which contains page remapping code.
> The other two files, which haven't changed much from April, can be
> found at http://people.valinux.co.jp/~iwamoto/mh.html .
	(snip)
> My patch supports remapping of normal pages, Takahashi's hugepage
> remapping patch will be posted in a few days.

I also post new hugepage remapping patches which is against linux-2.6.7.
I have change it to use objrmap so that the code become clean.

The patches can be downloaded from 
   http://people.valinux.co.jp/~taka/hpageremap.html .

There may remain some bugs. if you find them, would you let me know.

> I will be working on the following items.
> 
>   1.  Prototype implementation of memsection support.
>       It seems some people wants to hotremove small regions of memory
>       rather than zones or nodes.  A prototype implementation will
>       show how Takahashi's hugetlb page code can be used for such a
>       purpose.

This is my interst and I'll work on it.

>   2.  Handling of pages with dirty buffers without writing them back.
>       This is file system specific.  I plan to do against ext2 and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Perez-Gonzalez, Inaky | 2 Jul 2004 08:34
Picon
Favicon

Which is the proper way to bring in the backing store behind an inode as an struct page?

Hi all

Dummy question that has been evading me for the last hours. Can you
help? Please bear with me here, I am a little lost in how to deal
with inodes and the cache.

I have a problem where I have to modify a value in user space from 
inside a function called from do_exit() [this is for robust mutexes].
The reason for this is when a task exits holding a mutex, it needs to
update the user space word that represents the mutex to indicate that
it is dead. This is needed to allow for fast-lock operations when 
there is no mutex contention.

I need to be able to kmap the location where the page is so I can
modify it. The problem is that in one of the cases, when the thing 
is in a shared mapping (linear or non-linear), I just have the inode,
the page offset and the offset into the page.

Thus, what I need is a way that given the pair (inode,pgoff) 
returns to me the 'struct page *' if the thing is cached in memory or
pulls it up from swap/file into memory and gets me a 'struct page *'.

Is there a way to do this?

Thanks

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own (and my fault)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
(Continue reading)

Permalink | Reply | 2 comments |
headers
Chen, Kenneth W | 2 Jul 2004 20:07
Picon
Favicon

RE: Which is the proper way to bring in the backing store behind an inode as an struct page?

Perez-Gonzalez, Inaky wrote on Thursday, July 01, 2004 11:35 PM
> Dummy question that has been evading me for the last hours. Can you
> help? Please bear with me here, I am a little lost in how to deal
> with inodes and the cache.
>
> ....
>
> Thus, what I need is a way that given the pair (inode,pgoff)
> returns to me the 'struct page *' if the thing is cached in memory or
> pulls it up from swap/file into memory and gets me a 'struct page *'.
>
> Is there a way to do this?

find_get_page() might be the one you are looking for.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart <at> kvack.org"> aart <at> kvack.org </a>
Permalink | Reply | 0 comments |

Gmane