Rik van Riel's VM patch

Rik van Riel's VM patch

[John Levon]

Hi, this is just a short no-statistics testimony that Rik's VM patch
to test8-pre1 seems much improved over test7. I have a UP P200 with 40Mb,
and previously running KDE2 + mozilla was totally unusable. 

With the patch, things run much more smoothly. Interactive feel seems
better, and I don't have "swapping holidays" any more.

Heavily stressing it by g++ is better as well... 

just a data point,
john

-- 
"It's a damn poor mind that can only think of one way to spell a word."
	- Andrew Jackson

--
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.eu.org/Linux-MM/

Re: Rik van Riel's VM patch

[Bill Huey]

John,

> Hi, this is just a short no-statistics testimony that Rik's VM patch
> to test8-pre1 seems much improved over test7. I have a UP P200 with 40Mb,
> and previously running KDE2 + mozilla was totally unusable. 

> With the patch, things run much more smoothly. Interactive feel seems
> better, and I don't have "swapping holidays" any more.
 
> Heavily stressing it by g++ is better as well... 
> 
> just a data point,
> john

Yes, it kicks butt and it finally (just about) removes the final
Linux kernel showstopper for recent kernels. ;-)

I did a GNOME + KDE2 + c++ compile since I've been doing port work
and I have similar experiences.

bill

--
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.eu.org/Linux-MM/

Re: Rik van Riel's VM patch

[Byron Stanoszek]

On Sat, 2 Sep 2000, Bill Huey wrote:

> 
> John,
> 
> > Hi, this is just a short no-statistics testimony that Rik's VM patch
> > to test8-pre1 seems much improved over test7. I have a UP P200 with 40Mb,
> > and previously running KDE2 + mozilla was totally unusable. 
> 
> > With the patch, things run much more smoothly. Interactive feel seems
> > better, and I don't have "swapping holidays" any more.
>  
> > Heavily stressing it by g++ is better as well... 
> > 
> > just a data point,
> > john
> 
> Yes, it kicks butt and it finally (just about) removes the final
> Linux kernel showstopper for recent kernels. ;-)
> 
> I did a GNOME + KDE2 + c++ compile since I've been doing port work
> and I have similar experiences.
> 
> bill

This patch is plain awesome. It really sped up my 586 test machine (very
noticible when compiling XFree86.. which knocked off about a half hour of
compilation time), and there isn't a [noticable] memory leak like in the
old VM system before.

Good work, Rik. Tell us when it's integrated into the kernel. :)

-- 
Byron Stanoszek                         Ph: (330) 644-3059
Systems Programmer                      Fax: (330) 644-8110
Commercial Timesharing Inc.             Email: bstanoszek@comtime.com

--
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.eu.org/Linux-MM/

Re: Rik van Riel's VM patch

[Jeff V. Merkey]

Someone tell Rik to get his hands on a copy of AIMS-7 and start
benchmarking his VM so when the SCO Unix numbers hit the street, we've
got a rebuttal and fix dates to tell folks.

:-)

Jeff

Bill Huey wrote:
> 
> John,
> 
> > Hi, this is just a short no-statistics testimony that Rik's VM patch
> > to test8-pre1 seems much improved over test7. I have a UP P200 with 40Mb,
> > and previously running KDE2 + mozilla was totally unusable.
> 
> > With the patch, things run much more smoothly. Interactive feel seems
> > better, and I don't have "swapping holidays" any more.
> 
> > Heavily stressing it by g++ is better as well...
> >
> > just a data point,
> > john
> 
> Yes, it kicks butt and it finally (just about) removes the final
> Linux kernel showstopper for recent kernels. ;-)
> 
> I did a GNOME + KDE2 + c++ compile since I've been doing port work
> and I have similar experiences.
> 
> bill
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
--
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.eu.org/Linux-MM/

Re: Rik van Riel's VM patch

[Alan Cox]

> Yes, it kicks butt and it finally (just about) removes the final
> Linux kernel showstopper for recent kernels. ;-)

Things like random memory corruption from dropping dirty bits, and some of
the others are far more serious showstoppers alas

--
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.eu.org/Linux-MM/

Re: Rik van Riel's VM patch

[Rik van Riel]

On Sun, 3 Sep 2000, Alan Cox wrote:

> > Yes, it kicks butt and it finally (just about) removes the final
> > Linux kernel showstopper for recent kernels. ;-)
> 
> Things like random memory corruption from dropping dirty bits,
> and some of the others are far more serious showstoppers alas

Indeed, there are 4 major issues left in the VM area:

1) system hangs under load with 0 lowmem free (but still
   some high memory free)

   [not much details on this one yet]

2) dirty bits can get lost, try_to_swap_out() and other
   places have a race with the hardware

   [from mm/vmscan.c, line 60 has a race with the /hardware/]
     55         if (pte_young(pte)) {
     56                 /*
     57                  * Transfer the "accessed" bit from the page
     58                  * tables to the global page map.
     59                  */
     60                 set_pte(page_table, pte_mkold(pte));
     61                 SetPageReferenced(page);
     62                 goto out_failed;
     63         }

3) it appears something can corrupt page->count or delete a
   page from the cache while the page is locked

   [tripped up by my VM patch?]

4) the innd data corruption bug

   [anybody?]

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/

--
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.eu.org/Linux-MM/

Re: Rik van Riel's VM patch

[Peter Rival]

"Jeff V. Merkey" wrote:

> Someone tell Rik to get his hands on a copy of AIMS-7 and start
> benchmarking his VM so when the SCO Unix numbers hit the street, we've
> got a rebuttal and fix dates to tell folks.
>

That's going to be tough - AIM as a company is out of business (just go to
www.aim.com and be surprised ;).  And not to get off-topic, but there are bigger
problems with AIM7 tests than the VM (like the fact that they have hundreds of
runnable processes at any given time which our global run queue doesn't handle
well).  Really - pick something like SPECWeb99...oh, wait - we already destroy
the competition there... :)

 - Pete (still looking for a complete systemic test that's like AIM only more
realistic)

>
> :-)
>
> Jeff
>
> Bill Huey wrote:
> >
> > John,
> >
> > > Hi, this is just a short no-statistics testimony that Rik's VM patch
> > > to test8-pre1 seems much improved over test7. I have a UP P200 with 40Mb,
> > > and previously running KDE2 + mozilla was totally unusable.
> >
> > > With the patch, things run much more smoothly. Interactive feel seems
> > > better, and I don't have "swapping holidays" any more.
> >
> > > Heavily stressing it by g++ is better as well...
> > >
> > > just a data point,
> > > john
> >
> > Yes, it kicks butt and it finally (just about) removes the final
> > Linux kernel showstopper for recent kernels. ;-)
> >
> > I did a GNOME + KDE2 + c++ compile since I've been doing port work
> > and I have similar experiences.
> >
> > bill
> >
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > Please read the FAQ at http://www.tux.org/lkml/
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

--
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.eu.org/Linux-MM/

Re: Rik van Riel's VM patch

[Andrey Savochkin]

Hi,

On Sun, Sep 03, 2000 at 05:47:01PM -0300, Rik van Riel wrote:
> On Sun, 3 Sep 2000, Alan Cox wrote:
> 
> > Things like random memory corruption from dropping dirty bits,
> > and some of the others are far more serious showstoppers alas
> 
> Indeed, there are 4 major issues left in the VM area:
> 
[snip]
> 2) dirty bits can get lost, try_to_swap_out() and other
>    places have a race with the hardware
> 
>    [from mm/vmscan.c, line 60 has a race with the /hardware/]
>      55         if (pte_young(pte)) {
>      56                 /*
>      57                  * Transfer the "accessed" bit from the page
>      58                  * tables to the global page map.
>      59                  */
>      60                 set_pte(page_table, pte_mkold(pte));
>      61                 SetPageReferenced(page);
>      62                 goto out_failed;
>      63         }

I wonder about software races.
Page table manipulations in mm/memory.c are guarded by page_table_lock
against concurrent kswapd actions, with the following comments:
        /*
         * This is a long-lived spinlock. That's fine.
         * There's no contention, because the page table
         * lock only protects against kswapd anyway, and
         * even if kswapd happened to be looking at this
         * process we _want_ it to get stuck.
         */
and in the other place
 *
 * Note the "page_table_lock". It is to protect against kswapd removing
 * pages from under us. Note that kswapd only ever _removes_ pages, never
 * adds them. As such, once we have noticed that the page is not present,
 * we can drop the lock early.

Fine.  However, I don't see a trace of page_table_lock in swapping-out code!
And I don't see any other lock which may ensure the serialization.
Am I missing something?

	Andrey
--
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.eu.org/Linux-MM/