Abu M. Muttalib | 1 Aug 11:39 2006

the /proc/meminfo statistics

Hi,

I am running the following application.

#include<stdio.h>
#include<stdlib.h>

int main()
{
	unsigned char* arr;
	system("cat /proc/meminfo");
	sleep(25);
	arr = (char *)malloc (1048576);
	system("cat /proc/meminfo");
	sleep(25);
	free(arr);
	system("cat /proc/meminfo");
	sleep(25);
}

I am getting the following meminfo statistics. As I am allocating and
freeing 1024 kb, so I should get the same information through /proc/meminfo:

MemTotal:        14296 kB
MemFree:           912 kB
Buffers:          1448 kB
Cached:           5564 kB
SwapCached:          0 kB
Active:           5480 kB
Inactive:         3664 kB
(Continue reading)

Oleg Nesterov | 1 Aug 21:32 2006
Picon

Re: [patch 1/2] mm: speculative get_page

Nick Piggin wrote:
>
> --- linux-2.6.orig/mm/vmscan.c
> +++ linux-2.6/mm/vmscan.c
>  <at>  <at>  -380,6 +380,8  <at>  <at>  int remove_mapping(struct address_space 
>  	if (!mapping)
>  		return 0;		/* truncate got there first */
>
> +	SetPageNoNewRefs(page);
> +	smp_wmb();
>  	write_lock_irq(&mapping->tree_lock);
>

Is it enough?

PG_nonewrefs could be already set by another add_to_page_cache()/remove_mapping(),
and it will be cleared when we take ->tree_lock. For example:

CPU_0					CPU_1					CPU_3

add_to_page_cache:

    SetPageNoNewRefs();
    write_lock_irq(->tree_lock);
    ...
    write_unlock_irq(->tree_lock);

					remove_mapping:
	
					    SetPageNoNewRefs();
(Continue reading)

Dave Kleikamp | 1 Aug 17:55 2006
Picon

Re: [patch 1/2] mm: speculative get_page

On Tue, 2006-08-01 at 23:32 +0400, Oleg Nesterov wrote:
> Nick Piggin wrote:
> >
> > --- linux-2.6.orig/mm/vmscan.c
> > +++ linux-2.6/mm/vmscan.c
> >  <at>  <at>  -380,6 +380,8  <at>  <at>  int remove_mapping(struct address_space 
> >  	if (!mapping)
> >  		return 0;		/* truncate got there first */
> >
> > +	SetPageNoNewRefs(page);
> > +	smp_wmb();
> >  	write_lock_irq(&mapping->tree_lock);
> >
> 
> Is it enough?
> 
> PG_nonewrefs could be already set by another add_to_page_cache()/remove_mapping(),
> and it will be cleared when we take ->tree_lock.

Isn't the page locked when calling remove_mapping()?  It looks like
SetPageNoNewRefs & ClearPageNoNewRefs are called in safe places.  Either
the page is locked, or it's newly allocated.  I could have missed
something, though.

>  For example:
> 
> CPU_0					CPU_1					CPU_3
> 
> add_to_page_cache:
> 
(Continue reading)

Oleg Nesterov | 1 Aug 22:42 2006
Picon

Re: [patch 1/2] mm: speculative get_page

On 08/01, Dave Kleikamp wrote:
>
> On Tue, 2006-08-01 at 23:32 +0400, Oleg Nesterov wrote:
> > Nick Piggin wrote:
> > >
> > > --- linux-2.6.orig/mm/vmscan.c
> > > +++ linux-2.6/mm/vmscan.c
> > >  <at>  <at>  -380,6 +380,8  <at>  <at>  int remove_mapping(struct address_space 
> > >  	if (!mapping)
> > >  		return 0;		/* truncate got there first */
> > >
> > > +	SetPageNoNewRefs(page);
> > > +	smp_wmb();
> > >  	write_lock_irq(&mapping->tree_lock);
> > >
> > 
> > Is it enough?
> > 
> > PG_nonewrefs could be already set by another add_to_page_cache()/remove_mapping(),
> > and it will be cleared when we take ->tree_lock.
> 
> Isn't the page locked when calling remove_mapping()?  It looks like
> SetPageNoNewRefs & ClearPageNoNewRefs are called in safe places.  Either
> the page is locked, or it's newly allocated.  I could have missed
> something, though.

No, I think it is I who missed something, thanks.

Oleg.

(Continue reading)

Nick Piggin | 2 Aug 01:53 2006
Picon

Re: [patch 1/2] mm: speculative get_page

Oleg Nesterov wrote:
> On 08/01, Dave Kleikamp wrote:

>>Isn't the page locked when calling remove_mapping()?  It looks like
>>SetPageNoNewRefs & ClearPageNoNewRefs are called in safe places.  Either
>>the page is locked, or it's newly allocated.  I could have missed
>>something, though.
> 
> 
> No, I think it is I who missed something, thanks.

Yeah, SetPageNoNewRefs is indeed called only under PageLocked or for
newly allocated pages. I should make a note about that, as it isn't
immediately clear.

Thanks

--

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

Dave Hansen | 2 Aug 22:55 2006
Picon

[RFC][PATCH] enable VMSPLIT for highmem kernels


---

 lxc-dave/arch/i386/Kconfig |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN arch/i386/Kconfig~split-for-pae arch/i386/Kconfig
--- lxc/arch/i386/Kconfig~split-for-pae	2006-08-02 12:58:55.000000000 -0700
+++ lxc-dave/arch/i386/Kconfig	2006-08-02 13:02:55.000000000 -0700
 <at>  <at>  -497,7 +497,7  <at>  <at>  config HIGHMEM64G
 endchoice

 choice
-	depends on EXPERIMENTAL && !X86_PAE
+	depends on EXPERIMENTAL
 	prompt "Memory split" if EMBEDDED
 	default VMSPLIT_3G
 	help
 <at>  <at>  -519,6 +519,7  <at>  <at>  choice
 	config VMSPLIT_3G
 		bool "3G/1G user/kernel split"
 	config VMSPLIT_3G_OPT
+		depends on !HIGHMEM
 		bool "3G/1G user/kernel split (for full 1G low memory)"
 	config VMSPLIT_2G
 		bool "2G/2G user/kernel split"
_
Dave Hansen | 2 Aug 22:57 2006
Picon

Re: [RFC][PATCH] enable VMSPLIT for highmem kernels

Well, I somehow managed to post that without appending my description.
Here goes:

The current VMSPLIT Kconfig option is disabled whenever highmem
is on.  This is a bit screwy because the people who need to
change VMSPLIT the most tend to be the ones with highmem and
constrained lowmem.

So, remove the highmem dependency.  But, re-include the
dependency for the "full 1GB of lowmem" option.  You can't have
the full 1GB of lowmem and highmem because of the need for the
vmalloc(), kmap(), etc... areas.

I thought there would be at least a bit of tweaking to do to
get it to work, but everything seems OK.

Boot tested on a 4GB x86 machine, and a 12GB 3-node NUMA-Q:

elm3b82:~# cat /proc/meminfo
MemTotal:      3695412 kB
MemFree:       3659540 kB
...
LowTotal:      2909008 kB
LowFree:       2892324 kB
...
elm3b82:~# zgrep PAE /proc/config.gz
CONFIG_X86_PAE=y

larry:~# cat /proc/meminfo
MemTotal:     11845900 kB
(Continue reading)

Dave Hansen | 4 Aug 23:38 2006
Picon

[PATCH] enable VMSPLIT for highmem kernels


I'll assume that the complete lack of commenting on this patch
mean that everyone agrees with me. :)  Time for -mm I guess.

--

The current VMSPLIT Kconfig option is disabled whenever highmem
is on.  This is a bit screwy because the people who need to
change VMSPLIT the most tend to be the ones *with* highmem and
constrained lowmem.

So, remove the highmem dependency.  But, re-include the
dependency for the "full 1GB of lowmem" option.  You can't have
the full 1GB of lowmem and highmem because of the need for the
vmalloc(), kmap(), etc... areas.

I thought there would be at least a bit of tweaking to do to
get it to work, but everything seems OK.

Boot tested on a 4GB x86 machine, and a 12GB 3-node NUMA-Q:

elm3b82:~# cat /proc/meminfo
MemTotal:      3695412 kB
MemFree:       3659540 kB
...
LowTotal:      2909008 kB
LowFree:       2892324 kB
...
elm3b82:~# zgrep PAE /proc/config.gz
CONFIG_X86_PAE=y
(Continue reading)

Peter Zijlstra | 8 Aug 21:33 2006
Picon

[RFC][PATCH 0/9] Network receive deadlock prevention for NBD


From: Daniel Phillips <phillips <at> google.com>

Recently, Peter Zijlstra and I have been busily collaborating on a
solution to the memory deadlock problem described here:

   http://lwn.net/Articles/144273/
   "Kernel Summit 2005: Convergence of network and storage paths"

We believe that an approach very much like today's patch set is
necessary for NBD, iSCSI, AoE or the like ever to work reliably. 
We further believe that a properly working version of at least one of
these subsystems is critical to the viability of Linux as a modern
storage platform.

Today's patch set builds on a patch I posted a while back:

   http://lwn.net/Articles/146061/
   "Net vm deadlock fix (preliminary)"

Peter Zijlstra got the ball rolling again by posting this patch:

   http://lkml.org/lkml/2006/7/7/164

Which I gently flamed:

   http://lkml.org/lkml/2006/7/7/245

Peter turned out to be right. Any elevator other than NOOP is wrong for
NBD on the client side.  It turns out that something in the elevator
(Continue reading)

Peter Zijlstra | 8 Aug 21:33 2006
Picon

[RFC][PATCH 3/9] e1000 driver conversion


Update the driver to make use of the NETIF_F_MEMALLOC feature.

Signed-off-by: Peter Zijlstra <a.p.zijlstra <at> chello.nl>
Signed-off-by: Daniel Phillips <phillips <at> google.com>

---
 drivers/net/e1000/e1000_main.c |   11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

Index: linux-2.6/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.orig/drivers/net/e1000/e1000_main.c
+++ linux-2.6/drivers/net/e1000/e1000_main.c
 <at>  <at>  -822,7 +822,7  <at>  <at>  e1000_probe(struct pci_dev *pdev,
 	if (pci_using_dac)
 		netdev->features |= NETIF_F_HIGHDMA;

-	netdev->features |= NETIF_F_LLTX;
+	netdev->features |= NETIF_F_LLTX | NETIF_F_MEMALLOC;

 	adapter->en_mng_pt = e1000_enable_mng_pass_thru(&adapter->hw);

 <at>  <at>  -4020,8 +4020,6  <at>  <at>  e1000_alloc_rx_buffers(struct e1000_adap
 		 */
 		skb_reserve(skb, NET_IP_ALIGN);

-		skb->dev = netdev;
-
 		buffer_info->skb = skb;
(Continue reading)


Gmane