Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Peter Chubb]

Ingo wrote:
> On Wed, Jan 03, 2001 at 09:43:54AM -0200, Rik van Riel wrote:
> > On Fri, 28 Dec 2000, Mike Sklar wrote:
> > > If I wanted to adjust the rlim_cur value of a running
> > > processes, is there any sort of interface for that?
> > 
> > Hmmm, I don't think there is an interface to adjust the
> > per-process ulimit settings on-the-fly ...
> > 
> > Does anybody know if there's an interface for this ?

> If you don't mean "kill -TERM", no there isn't. It would be evil
> to the process anyway.

The RSS limits patch I sent to linux-kernel some time ago provided an
experimental /proc interface to allow exactly this.
The patch against 2.2.16 is still on our FTP server at 

ftp://ftp-au.aurema.com/private/aurpjc31/linux-2216-rsslimit.diff.bz2

Here's the patch against 2.4.0.  The main differences between this and 
Rik's patch are:
  -- you  choose soft or hard limits at kernel config time with my 
  patch; with Rik's you get both (rlim_cur is `soft' rlim_max is
  `hard') 
  -- Rik's patch does some extra stuff to the VM code as well as
 the RSS limits
  -- Rik's patch doesn't affect swap behaviour (except in so far
 as processes over their RSS limit will tend to swap, which reduces
 memory pressure on all other processes); my patch means that
 processes over RSS limit suffer somewhat
  -- My patch puts the limit into the struct mm for slightly more
 cache-friendly behaviour, and to allow later interfacing with
 per-user resource-management software (it should be possible
 to write a kernel module to adjust RSS limits to implement per-user 
 limits without affecting per-process RLIMIT values)
  -- My patch has a /proc interface to allow setting
 rlimit[RLIMIT_RSS]
  -- my patch implements the rss accounting fields so that time -v 
 gives reasonable output


Index: linux-2.4.0/CREDITS
===
RCS file: /wrk/CVSROOT/linux-2.4/CREDITS,v
retrieving revision 1.1.1.5
diff -u -b -u -r1.1.1.5 CREDITS
--- linux-2.4.0/CREDITS 2001/01/04 23:02:54 1.1.1.5
+++ linux-2.4.0/CREDITS 2001/01/08 04:41:41
@@ -491,6 +491,24 @@
 S: Stanford, California 94305
 S: USA
 
+N: Kingsley Cheung
+E: [EMAIL PROTECTED]
+D: Page fault calculation
+D: /proc//rss support
+D: kswapd improvements regarding process RSS limits 
+S: Aurema Pty Limited
+S: PO Box 305, Strawberry Hills NSW 2012, 
+S: Australia 
+
+N: Peter Chubb
+E: [EMAIL PROTECTED]
+D: Page fault calculation
+D: /proc//rss support
+D: kswapd improvements regarding process RSS limits 
+S: Aurema Pty Limited
+S: PO Box 305, Strawberry Hills NSW 2012, 
+S: Australia 
+
 N: Juan Jose Ciarlante
 W: http://juanjox.kernelnotes.org/
 E: [EMAIL PROTECTED]
Index: linux-2.4.0/Documentation/Configure.help
===
RCS file: /wrk/CVSROOT/linux-2.4/Documentation/Configure.help,v
retrieving revision 1.1.1.6
diff -u -b -u -r1.1.1.6 Configure.help
--- linux-2.4.0/Documentation/Configure.help2001/01/07 21:44:33 1.1.1.6
+++ linux-2.4.0/Documentation/Configure.help2001/01/08 04:41:41
@@ -16955,6 +16955,50 @@
   another UltraSPARC-IIi-cEngine boardset with a 7-segment display,
   you should say N to this option. 
 
+RSS Softlimits (EXPERIMENTAL)
+CONFIG_RSS_SOFTLIMIT
+  If you want the setrlimit(RLIMIT_RSS, ...) system call to work, say
+  Y either here or for RSS Hardlimits.  If you don't understand this
+  you don't need it, so say N.
+
+  RSS Softlimits will make it more likely that pages will be stolen
+  from processes that have a resident set size (i.e., real memory
+  footprint) greater than their limit.  Processes with a limit set
+  that is below their actual need may still exceed their limits, and
+  in this instance kswapd may work excessively hard.
+
+  Because of the way that RSS is measured and controlled, the limit is
+  approximate only.
+
+  It is harmless to have RSS Softlimits and RSS Hardlimits both set.
+
+RSS Hardlimits (EXPERIMENTAL)
+CONFIG_RSS_HARDLIMIT
+  If you want the setrlimit(RLIMIT_RSS, ...) system call to work, say
+  Y either here or for RSS Softlimits.  If you don't understand this
+  you don't need it, so say N.
+
+  RSS Hardlimits changes the behaviour of the kernel at page-fault
+  time.  If a process is over its RSS limit when it wants to get a new
+  page, then with this configuration option enabled the process's
+  memory space will be reduced before the page-fault continues.
+
+  Because of the way that RSS is measured and controlled, the actual
+  memory footprint of a process may exceed the set limit for a short
+  time.
+
+  It is harmless to have RSS Softlimits and RSS Hardlimits both set.
+
+Support for /proc/pid/rss (EXPERIMENTAL)
+CONFIG_PROC_RSS
+  Saying Y here adds an extra file inside each process directory in the
+  /proc file system that allows measurement and control of resident
+  set size (real 

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Peter Chubb]

Ingo wrote:
 On Wed, Jan 03, 2001 at 09:43:54AM -0200, Rik van Riel wrote:
  On Fri, 28 Dec 2000, Mike Sklar wrote:
   If I wanted to adjust the rlim_cur value of a running
   processes, is there any sort of interface for that?
  
  Hmmm, I don't think there is an interface to adjust the
  per-process ulimit settings on-the-fly ...
  
  Does anybody know if there's an interface for this ?

 If you don't mean "kill -TERM", no there isn't. It would be evil
 to the process anyway.

The RSS limits patch I sent to linux-kernel some time ago provided an
experimental /proc interface to allow exactly this.
The patch against 2.2.16 is still on our FTP server at 

ftp://ftp-au.aurema.com/private/aurpjc31/linux-2216-rsslimit.diff.bz2

Here's the patch against 2.4.0.  The main differences between this and 
Rik's patch are:
  -- you  choose soft or hard limits at kernel config time with my 
  patch; with Rik's you get both (rlim_cur is `soft' rlim_max is
  `hard') 
  -- Rik's patch does some extra stuff to the VM code as well as
 the RSS limits
  -- Rik's patch doesn't affect swap behaviour (except in so far
 as processes over their RSS limit will tend to swap, which reduces
 memory pressure on all other processes); my patch means that
 processes over RSS limit suffer somewhat
  -- My patch puts the limit into the struct mm for slightly more
 cache-friendly behaviour, and to allow later interfacing with
 per-user resource-management software (it should be possible
 to write a kernel module to adjust RSS limits to implement per-user 
 limits without affecting per-process RLIMIT values)
  -- My patch has a /proc interface to allow setting
 rlimit[RLIMIT_RSS]
  -- my patch implements the rss accounting fields so that time -v 
 gives reasonable output


Index: linux-2.4.0/CREDITS
===
RCS file: /wrk/CVSROOT/linux-2.4/CREDITS,v
retrieving revision 1.1.1.5
diff -u -b -u -r1.1.1.5 CREDITS
--- linux-2.4.0/CREDITS 2001/01/04 23:02:54 1.1.1.5
+++ linux-2.4.0/CREDITS 2001/01/08 04:41:41
@@ -491,6 +491,24 @@
 S: Stanford, California 94305
 S: USA
 
+N: Kingsley Cheung
+E: [EMAIL PROTECTED]
+D: Page fault calculation
+D: /proc/pid/rss support
+D: kswapd improvements regarding process RSS limits 
+S: Aurema Pty Limited
+S: PO Box 305, Strawberry Hills NSW 2012, 
+S: Australia 
+
+N: Peter Chubb
+E: [EMAIL PROTECTED]
+D: Page fault calculation
+D: /proc/pid/rss support
+D: kswapd improvements regarding process RSS limits 
+S: Aurema Pty Limited
+S: PO Box 305, Strawberry Hills NSW 2012, 
+S: Australia 
+
 N: Juan Jose Ciarlante
 W: http://juanjox.kernelnotes.org/
 E: [EMAIL PROTECTED]
Index: linux-2.4.0/Documentation/Configure.help
===
RCS file: /wrk/CVSROOT/linux-2.4/Documentation/Configure.help,v
retrieving revision 1.1.1.6
diff -u -b -u -r1.1.1.6 Configure.help
--- linux-2.4.0/Documentation/Configure.help2001/01/07 21:44:33 1.1.1.6
+++ linux-2.4.0/Documentation/Configure.help2001/01/08 04:41:41
@@ -16955,6 +16955,50 @@
   another UltraSPARC-IIi-cEngine boardset with a 7-segment display,
   you should say N to this option. 
 
+RSS Softlimits (EXPERIMENTAL)
+CONFIG_RSS_SOFTLIMIT
+  If you want the setrlimit(RLIMIT_RSS, ...) system call to work, say
+  Y either here or for RSS Hardlimits.  If you don't understand this
+  you don't need it, so say N.
+
+  RSS Softlimits will make it more likely that pages will be stolen
+  from processes that have a resident set size (i.e., real memory
+  footprint) greater than their limit.  Processes with a limit set
+  that is below their actual need may still exceed their limits, and
+  in this instance kswapd may work excessively hard.
+
+  Because of the way that RSS is measured and controlled, the limit is
+  approximate only.
+
+  It is harmless to have RSS Softlimits and RSS Hardlimits both set.
+
+RSS Hardlimits (EXPERIMENTAL)
+CONFIG_RSS_HARDLIMIT
+  If you want the setrlimit(RLIMIT_RSS, ...) system call to work, say
+  Y either here or for RSS Softlimits.  If you don't understand this
+  you don't need it, so say N.
+
+  RSS Hardlimits changes the behaviour of the kernel at page-fault
+  time.  If a process is over its RSS limit when it wants to get a new
+  page, then with this configuration option enabled the process's
+  memory space will be reduced before the page-fault continues.
+
+  Because of the way that RSS is measured and controlled, the actual
+  memory footprint of a process may exceed the set limit for a short
+  time.
+
+  It is harmless to have RSS Softlimits and RSS Hardlimits both set.
+
+Support for /proc/pid/rss (EXPERIMENTAL)
+CONFIG_PROC_RSS
+  Saying Y here adds an extra file inside each process directory in the
+  /proc file system that allows measurement and control of resident
+  set size (real memory 

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Ingo Oeser]

On Wed, Jan 03, 2001 at 09:43:54AM -0200, Rik van Riel wrote:
> On Fri, 28 Dec 2000, Mike Sklar wrote:
> > If I wanted to adjust the rlim_cur value of a running
> > processes, is there any sort of interface for that?
> 
> Hmmm, I don't think there is an interface to adjust the
> per-process ulimit settings on-the-fly ...
> 
> Does anybody know if there's an interface for this ?

If you don't mean "kill -TERM", no there isn't. It would be evil
to the process anyway.

Some[1] programs ask their resource limits on startup to scale to a
sane amount of memory usage for caching, operation buffers and
the like. If your readjust it to sth. smaller, they'll be killed
soon and if you readjust to sth, bigger, they wouldn't use it.


Regards

Ingo Oeser

[1] I would like to write "most programs", but most programs
   assume, that they will never run out of memory and leave it to
   the administrator/user to care for this issue :-(
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag 
    come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Rik van Riel]

On Fri, 28 Dec 2000, Mike Sklar wrote:

> If I wanted to adjust the rlim_cur value of a running
> processes, is there any sort of interface for that?

Hmmm, I don't think there is an interface to adjust the
per-process ulimit settings on-the-fly ...

Does anybody know if there's an interface for this ?

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Rik van Riel]

On Fri, 28 Dec 2000, Mike Sklar wrote:

 If I wanted to adjust the rlim_cur value of a running
 processes, is there any sort of interface for that?

Hmmm, I don't think there is an interface to adjust the
per-process ulimit settings on-the-fly ...

Does anybody know if there's an interface for this ?

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Ingo Oeser]

On Wed, Jan 03, 2001 at 09:43:54AM -0200, Rik van Riel wrote:
 On Fri, 28 Dec 2000, Mike Sklar wrote:
  If I wanted to adjust the rlim_cur value of a running
  processes, is there any sort of interface for that?
 
 Hmmm, I don't think there is an interface to adjust the
 per-process ulimit settings on-the-fly ...
 
 Does anybody know if there's an interface for this ?

If you don't mean "kill -TERM", no there isn't. It would be evil
to the process anyway.

Some[1] programs ask their resource limits on startup to scale to a
sane amount of memory usage for caching, operation buffers and
the like. If your readjust it to sth. smaller, they'll be killed
soon and if you readjust to sth, bigger, they wouldn't use it.


Regards

Ingo Oeser

[1] I would like to write "most programs", but most programs
   assume, that they will never run out of memory and leave it to
   the administrator/user to care for this issue :-(
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag http://www.tu-chemnitz.de/linux/tag
come and join the fun   
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[H. Peter Anvin]

Followup to:  <[EMAIL PROTECTED]>
By author:Geert Uytterhoeven <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> 
> What about defining new types for this? Like e.g. `x8', being `u8' on platforms
> were that's OK, and `u32' on platforms where that's more efficient?
> 

You may just want to look at how C99 handles this using ;
stdint.h defines types of the following format:

 int, uint  ... signed/unsigned

  ... exact size
 _least   ... no smaller than
 _fast... no smaller than, and efficient

 _t

E.g. uint32_t, int_least64_t, uint_fast8_t (the latter could easily be
a 32-bit type, for eaxmple.)

In addition, constructor macros are defined, as well as (u)intmax_t
and (u)intptr_t; which are defined as the largest
possible integer and an integer large enough to hold a (void *),
respectively.

In other words:

(void *)(uintptr_t)(void *)foo == (void *)foo

-hpa

-- 
<[EMAIL PROTECTED]> at work, <[EMAIL PROTECTED]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[H. Peter Anvin]

Followup to:  [EMAIL PROTECTED]
By author:Geert Uytterhoeven [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
 
 What about defining new types for this? Like e.g. `x8', being `u8' on platforms
 were that's OK, and `u32' on platforms where that's more efficient?
 

You may just want to look at how C99 handles this using stdint.h;
stdint.h defines types of the following format:

 int, uint  ... signed/unsigned

 size ... exact size
 _leastsize   ... no smaller than
 _fastsize... no smaller than, and efficient

 _t

E.g. uint32_t, int_least64_t, uint_fast8_t (the latter could easily be
a 32-bit type, for eaxmple.)

In addition, constructor macros are defined, as well as (u)intmax_t
and (u)intptr_t; which are defined as the largest
possible integer and an integer large enough to hold a (void *),
respectively.

In other words:

(void *)(uintptr_t)(void *)foo == (void *)foo

-hpa

-- 
[EMAIL PROTECTED] at work, [EMAIL PROTECTED] in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Sun, Dec 31, 2000 at 11:15:51AM -0800, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>,
> Matti Aarnio  <[EMAIL PROTECTED]> wrote:
> >
> > Actually nothing SMP specific in that problem sphere.
> > Alpha has  load-locked/store-conditional  pair for
> > this type of memory accesses to automatically detect,
> > and (conditionally) restart the operation - to form
> > classical  ``locked-read-modify-write'' operations.
> 
> Sure, we could make the older alphas use ldl_l stl_c for byte accesses,
> but if you thought byte accesses on those machines were kind-of slow
> before, just WAIT until that happens.

The older Alphas would just typedef x8/x16 (or granular_u8, granular_u16
or whatever it is called) to u32 and be the same as today. Just most
other boxes would benefit.

This actually all assumes that gcc really uses the byte instructions
for byte stores in structures, which is to be determined.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

In article <[EMAIL PROTECTED]>,
Matti Aarnio  <[EMAIL PROTECTED]> wrote:
>
>   Actually nothing SMP specific in that problem sphere.
>   Alpha has  load-locked/store-conditional  pair for
>   this type of memory accesses to automatically detect,
>   and (conditionally) restart the operation - to form
>   classical  ``locked-read-modify-write'' operations.

Sure, we could make the older alphas use ldl_l stl_c for byte accesses,
but if you thought byte accesses on those machines were kind-of slow
before, just WAIT until that happens.

Old alpha machines (the same ones that would need this code) were
HORRIBLE at ldl_l<->stl_c: they go out all the way to the bus to set the
lock.  So suddenly your every byte access ends up being a few hundred
cycles!

So ldl_l/stc_l is not the answer.  It would work, but it would be so
slow that you'd be a lot better off not doing it. 

I think they fixed ldl/stc later on (so that it only sets a bit locally
that gets cleared by the cache coherency protocol), but as later alphas
have the byte accesses anyway that doesn't matter here. The faster
ldl/stc makes for much faster spinlocks on newer alphas, though.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andrea Arcangeli]

On Sun, Dec 31, 2000 at 06:36:50PM +0100, Andi Kleen wrote:
> AFAIK alpha has byte instructions now.

See other post. Only from ev6 (at least as far as gcc is concerned). I've an
userspace testcase here (it was originally an obscure alpha userspace MM
corruption bug report that I sorted out some time ago) that works only only
when compiled for ev6 because it needs `short' granularity (not even byte
granularity).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andrea Arcangeli]

On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
> The alpha systems I remember this problem on were all [..]

Yes the granularity issue has nothing to do with SMP (with preemptive kernel
it can trigger even without interrupts involved into the code). Also
CONFIG_SPACE_EFFICIENT looks not necessary.

The x8 name is confusing IMHO (when I read `8' I expect 8bits only, the x
isn't explicit enough). But by using a better name we could save some byte on
alpha ev6 and x86. Something like granular_char/granular_short/granular_int
looks nicer.  For the generic 64bit cpu they needs to be _unconditionally_
defined to `long'.

BTW, only old chips (ev[45]) doesn't provide byte granularity. Infact a linux
kernel compiled for ev6 can handle byte granularity also on alpha (it uses
-mcpu=ev6).

alpha reference manual 5.2.2:

[..] For each region, an implementation must support aligned quadword
access and may optionally support aligned longword access or byte
access. If byte access is supported in a region, aligned word access
and aligned longword access are also supported. [..]

21264hrm:

[..] The 21264-generated external references to memory space are
always of a fixed 64-byte size, though the internal access granularity
is byte, word, longword, or quad-word. [..]

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Matti Aarnio]

On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
> On Sun, 31 Dec 2000, Andi Kleen wrote:
> > 
> > Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
> > embedded systems, where you could trade a bit of CPU for less memory overhead 
> > even on systems where u8 is slow and atomicity doesn't come into play
> > because it's UP anyways. 
> 
> UP has nothing to do with it.
> The alpha systems I remember this problem on were all SMP.

Actually nothing SMP specific in that problem sphere.
Alpha has  load-locked/store-conditional  pair for
this type of memory accesses to automatically detect,
and (conditionally) restart the operation - to form
classical  ``locked-read-modify-write'' operations.

In what situations the compiler will use those instructions,
that I don't know.   Volatiles, very least, use them.
Will closely packed bytes be processed with it without
them being volatiles ?  How about bitfields ?

Newer Alphas have byte/short load/store instructions,
so things really aren't that straight-forward...


> I don't think it's a good diea.
> 
>   Linus

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
> 
> 
> On Sun, 31 Dec 2000, Andi Kleen wrote:
> > 
> > Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
> > embedded systems, where you could trade a bit of CPU for less memory overhead 
> > even on systems where u8 is slow and atomicity doesn't come into play
> > because it's UP anyways. 
> 
> UP has nothing to do with it.
> 
> The alpha systems I remember this problem on were all SMP.
[...]

I just checked all architecture manuals I could lay my hands on
(sparcv9, ppc32, mips r4400, parisc 1.1, alpha, sh is somewhere in
storage but as I remember it has it too) 
and they all seem to have at least store byte and mostly store
half words instructions. 

> 
> Imagine an architecture where you need to do a
> 
>   load_32() 
>   mask-and-insert-byte
>   store_32()

iirc the Alpha guys found out that they couldn't drive half of the
available devices without byte store, and since then nobody has 
repeated that mistake @)


> 
> I don't think it's a good diea.

I don't see it. Just define x8 to u32 on old alpha and let most other architectures
be happy. 


-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
> 
> 
> On Sun, 31 Dec 2000, Andi Kleen wrote:
> > 
> > Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
> > embedded systems, where you could trade a bit of CPU for less memory overhead 
> > even on systems where u8 is slow and atomicity doesn't come into play
> > because it's UP anyways. 
> 
> UP has nothing to do with it.
> 
> The alpha systems I remember this problem on were all SMP.

AFAIK alpha has byte instructions now.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Sun, 31 Dec 2000, Andi Kleen wrote:
> 
> Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
> embedded systems, where you could trade a bit of CPU for less memory overhead 
> even on systems where u8 is slow and atomicity doesn't come into play
> because it's UP anyways. 

UP has nothing to do with it.

The alpha systems I remember this problem on were all SMP.

Imagine an architecture where you need to do a

load_32()
mask-and-insert-byte
store_32()

and imagine that an interrupt comes in:

load_32()
mask-and-insert-byte

* INTERRUPT *

load_32()
mask-and-insert-ANOTHER-byte
store_32()

interrupt return

store_32()

and notice how the value written by the interrupt is gone, gone, gone,
even though it was to a completely different byte.

Now, imagine that the first byte is the "age", and imagine that the thing
the interrupt tries to update is "flags".

Yes, you're screwed.

I don't think it's a good diea.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Sat, Dec 30, 2000 at 02:24:06PM +0100, Geert Uytterhoeven wrote:
> On Thu, 28 Dec 2000, Linus Torvalds wrote:
> > On Thu, 28 Dec 2000, Andi Kleen wrote:
> > > - Instead of having a zone pointer mask use a 8 or 16 byte index into a 
> > > zone table. On a modern CPU it is much cheaper to do the and/shifts than
> > > to do even a single cache miss during page aging. On a lot of systems 
> > > that zone index could be hardcoded to 0 anyways, giving better code.
> > > - Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which
> > > has the same swapping algorithm even only uses 8bit) 
> > 
> > This would be good, but can be hard.
> > 
> > FreeBSD doesn't try to be portable any more, but Linux does, and there are
> > architectures where 8- and 16-bit accesses aren't atomic but have to be
> > done with read-modify-write cycles.
> > 
> > And even for fields like "age", where we don't care whether the age itself
> > is 100% accurate, we _do_ care that the fields close-by don't get strange
> > effects from updating "age". We used to have exactly this problem on alpha
> > back in the 2.1.x timeframe.
> > 
> > This is why a lot of fields are 32-bit, even though we wouldn't need more
> > than 8 or 16 bits of them.
> 
> What about defining new types for this? Like e.g. `x8', being `u8' on platforms
> were that's OK, and `u32' on platforms where that's more efficient?

Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
embedded systems, where you could trade a bit of CPU for less memory overhead 
even on systems where u8 is slow and atomicity doesn't come into play
because it's UP anyways. 

Only problem I see is that when the programmer was wrong about the possible
range (which sometimes happens) then it could mysteriously work on some
machines and fail on others. This is already the case e.g. with atomic_t,
which is shorter than 32bit e.g. on sparc32, so it is probably not a too
big problem. 


-Andi

/* asm/types.h for a random 32bit machine with no byte access */ 
#if defined(CONFIG_SPACE_EFFICIENT) && !defined(CONFIG_SMP)
typedef __u8 x8; 
typedef __u16 x16; 
typedef __u32 x32; 
#else
typedef __u32 x8; 
typedef __u32 x16; 
typedef __u32 x32; 
#endif

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Geert Uytterhoeven]

On Thu, 28 Dec 2000, Linus Torvalds wrote:
> On Thu, 28 Dec 2000, Andi Kleen wrote:
> > - Instead of having a zone pointer mask use a 8 or 16 byte index into a 
> > zone table. On a modern CPU it is much cheaper to do the and/shifts than
> > to do even a single cache miss during page aging. On a lot of systems 
> > that zone index could be hardcoded to 0 anyways, giving better code.
> > - Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which
> > has the same swapping algorithm even only uses 8bit) 
> 
> This would be good, but can be hard.
> 
> FreeBSD doesn't try to be portable any more, but Linux does, and there are
> architectures where 8- and 16-bit accesses aren't atomic but have to be
> done with read-modify-write cycles.
> 
> And even for fields like "age", where we don't care whether the age itself
> is 100% accurate, we _do_ care that the fields close-by don't get strange
> effects from updating "age". We used to have exactly this problem on alpha
> back in the 2.1.x timeframe.
> 
> This is why a lot of fields are 32-bit, even though we wouldn't need more
> than 8 or 16 bits of them.

What about defining new types for this? Like e.g. `x8', being `u8' on platforms
were that's OK, and `u32' on platforms where that's more efficient?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Geert Uytterhoeven]

On Thu, 28 Dec 2000, Linus Torvalds wrote:
 On Thu, 28 Dec 2000, Andi Kleen wrote:
  - Instead of having a zone pointer mask use a 8 or 16 byte index into a 
  zone table. On a modern CPU it is much cheaper to do the and/shifts than
  to do even a single cache miss during page aging. On a lot of systems 
  that zone index could be hardcoded to 0 anyways, giving better code.
  - Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which
  has the same swapping algorithm even only uses 8bit) 
 
 This would be good, but can be hard.
 
 FreeBSD doesn't try to be portable any more, but Linux does, and there are
 architectures where 8- and 16-bit accesses aren't atomic but have to be
 done with read-modify-write cycles.
 
 And even for fields like "age", where we don't care whether the age itself
 is 100% accurate, we _do_ care that the fields close-by don't get strange
 effects from updating "age". We used to have exactly this problem on alpha
 back in the 2.1.x timeframe.
 
 This is why a lot of fields are 32-bit, even though we wouldn't need more
 than 8 or 16 bits of them.

What about defining new types for this? Like e.g. `x8', being `u8' on platforms
were that's OK, and `u32' on platforms where that's more efficient?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Sat, Dec 30, 2000 at 02:24:06PM +0100, Geert Uytterhoeven wrote:
 On Thu, 28 Dec 2000, Linus Torvalds wrote:
  On Thu, 28 Dec 2000, Andi Kleen wrote:
   - Instead of having a zone pointer mask use a 8 or 16 byte index into a 
   zone table. On a modern CPU it is much cheaper to do the and/shifts than
   to do even a single cache miss during page aging. On a lot of systems 
   that zone index could be hardcoded to 0 anyways, giving better code.
   - Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which
   has the same swapping algorithm even only uses 8bit) 
  
  This would be good, but can be hard.
  
  FreeBSD doesn't try to be portable any more, but Linux does, and there are
  architectures where 8- and 16-bit accesses aren't atomic but have to be
  done with read-modify-write cycles.
  
  And even for fields like "age", where we don't care whether the age itself
  is 100% accurate, we _do_ care that the fields close-by don't get strange
  effects from updating "age". We used to have exactly this problem on alpha
  back in the 2.1.x timeframe.
  
  This is why a lot of fields are 32-bit, even though we wouldn't need more
  than 8 or 16 bits of them.
 
 What about defining new types for this? Like e.g. `x8', being `u8' on platforms
 were that's OK, and `u32' on platforms where that's more efficient?

Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
embedded systems, where you could trade a bit of CPU for less memory overhead 
even on systems where u8 is slow and atomicity doesn't come into play
because it's UP anyways. 

Only problem I see is that when the programmer was wrong about the possible
range (which sometimes happens) then it could mysteriously work on some
machines and fail on others. This is already the case e.g. with atomic_t,
which is shorter than 32bit e.g. on sparc32, so it is probably not a too
big problem. 


-Andi

/* asm/types.h for a random 32bit machine with no byte access */ 
#if defined(CONFIG_SPACE_EFFICIENT)  !defined(CONFIG_SMP)
typedef __u8 x8; 
typedef __u16 x16; 
typedef __u32 x32; 
#else
typedef __u32 x8; 
typedef __u32 x16; 
typedef __u32 x32; 
#endif

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Sun, 31 Dec 2000, Andi Kleen wrote:
 
 Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
 embedded systems, where you could trade a bit of CPU for less memory overhead 
 even on systems where u8 is slow and atomicity doesn't come into play
 because it's UP anyways. 

UP has nothing to do with it.

The alpha systems I remember this problem on were all SMP.

Imagine an architecture where you need to do a

load_32()
mask-and-insert-byte
store_32()

and imagine that an interrupt comes in:

load_32()
mask-and-insert-byte

* INTERRUPT *

load_32()
mask-and-insert-ANOTHER-byte
store_32()

interrupt return

store_32()

and notice how the value written by the interrupt is gone, gone, gone,
even though it was to a completely different byte.

Now, imagine that the first byte is the "age", and imagine that the thing
the interrupt tries to update is "flags".

Yes, you're screwed.

I don't think it's a good diea.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
 
 
 On Sun, 31 Dec 2000, Andi Kleen wrote:
  
  Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
  embedded systems, where you could trade a bit of CPU for less memory overhead 
  even on systems where u8 is slow and atomicity doesn't come into play
  because it's UP anyways. 
 
 UP has nothing to do with it.
 
 The alpha systems I remember this problem on were all SMP.

AFAIK alpha has byte instructions now.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
 
 
 On Sun, 31 Dec 2000, Andi Kleen wrote:
  
  Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
  embedded systems, where you could trade a bit of CPU for less memory overhead 
  even on systems where u8 is slow and atomicity doesn't come into play
  because it's UP anyways. 
 
 UP has nothing to do with it.
 
 The alpha systems I remember this problem on were all SMP.
[...]

I just checked all architecture manuals I could lay my hands on
(sparcv9, ppc32, mips r4400, parisc 1.1, alpha, sh is somewhere in
storage but as I remember it has it too) 
and they all seem to have at least store byte and mostly store
half words instructions. 

 
 Imagine an architecture where you need to do a
 
   load_32() 
   mask-and-insert-byte
   store_32()

iirc the Alpha guys found out that they couldn't drive half of the
available devices without byte store, and since then nobody has 
repeated that mistake @)


 
 I don't think it's a good diea.

I don't see it. Just define x8 to u32 on old alpha and let most other architectures
be happy. 


-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Matti Aarnio]

On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
 On Sun, 31 Dec 2000, Andi Kleen wrote:
  
  Sounds good. It could also be controlled by a CONFIG_SPACE_EFFICIENT for
  embedded systems, where you could trade a bit of CPU for less memory overhead 
  even on systems where u8 is slow and atomicity doesn't come into play
  because it's UP anyways. 
 
 UP has nothing to do with it.
 The alpha systems I remember this problem on were all SMP.

Actually nothing SMP specific in that problem sphere.
Alpha has  load-locked/store-conditional  pair for
this type of memory accesses to automatically detect,
and (conditionally) restart the operation - to form
classical  ``locked-read-modify-write'' operations.

In what situations the compiler will use those instructions,
that I don't know.   Volatiles, very least, use them.
Will closely packed bytes be processed with it without
them being volatiles ?  How about bitfields ?

Newer Alphas have byte/short load/store instructions,
so things really aren't that straight-forward...


 I don't think it's a good diea.
 
   Linus

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andrea Arcangeli]

On Sun, Dec 31, 2000 at 09:27:23AM -0800, Linus Torvalds wrote:
 The alpha systems I remember this problem on were all [..]

Yes the granularity issue has nothing to do with SMP (with preemptive kernel
it can trigger even without interrupts involved into the code). Also
CONFIG_SPACE_EFFICIENT looks not necessary.

The x8 name is confusing IMHO (when I read `8' I expect 8bits only, the x
isn't explicit enough). But by using a better name we could save some byte on
alpha ev6 and x86. Something like granular_char/granular_short/granular_int
looks nicer.  For the generic 64bit cpu they needs to be _unconditionally_
defined to `long'.

BTW, only old chips (ev[45]) doesn't provide byte granularity. Infact a linux
kernel compiled for ev6 can handle byte granularity also on alpha (it uses
-mcpu=ev6).

alpha reference manual 5.2.2:

[..] For each region, an implementation must support aligned quadword
access and may optionally support aligned longword access or byte
access. If byte access is supported in a region, aligned word access
and aligned longword access are also supported. [..]

21264hrm:

[..] The 21264-generated external references to memory space are
always of a fixed 64-byte size, though the internal access granularity
is byte, word, longword, or quad-word. [..]

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andrea Arcangeli]

On Sun, Dec 31, 2000 at 06:36:50PM +0100, Andi Kleen wrote:
 AFAIK alpha has byte instructions now.

See other post. Only from ev6 (at least as far as gcc is concerned). I've an
userspace testcase here (it was originally an obscure alpha userspace MM
corruption bug report that I sorted out some time ago) that works only only
when compiled for ev6 because it needs `short' granularity (not even byte
granularity).

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

In article [EMAIL PROTECTED],
Matti Aarnio  [EMAIL PROTECTED] wrote:

   Actually nothing SMP specific in that problem sphere.
   Alpha has  load-locked/store-conditional  pair for
   this type of memory accesses to automatically detect,
   and (conditionally) restart the operation - to form
   classical  ``locked-read-modify-write'' operations.

Sure, we could make the older alphas use ldl_l stl_c for byte accesses,
but if you thought byte accesses on those machines were kind-of slow
before, just WAIT until that happens.

Old alpha machines (the same ones that would need this code) were
HORRIBLE at ldl_l-stl_c: they go out all the way to the bus to set the
lock.  So suddenly your every byte access ends up being a few hundred
cycles!

So ldl_l/stc_l is not the answer.  It would work, but it would be so
slow that you'd be a lot better off not doing it. 

I think they fixed ldl/stc later on (so that it only sets a bit locally
that gets cleared by the cache coherency protocol), but as later alphas
have the byte accesses anyway that doesn't matter here. The faster
ldl/stc makes for much faster spinlocks on newer alphas, though.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Sun, Dec 31, 2000 at 11:15:51AM -0800, Linus Torvalds wrote:
 In article [EMAIL PROTECTED],
 Matti Aarnio  [EMAIL PROTECTED] wrote:
 
  Actually nothing SMP specific in that problem sphere.
  Alpha has  load-locked/store-conditional  pair for
  this type of memory accesses to automatically detect,
  and (conditionally) restart the operation - to form
  classical  ``locked-read-modify-write'' operations.
 
 Sure, we could make the older alphas use ldl_l stl_c for byte accesses,
 but if you thought byte accesses on those machines were kind-of slow
 before, just WAIT until that happens.

The older Alphas would just typedef x8/x16 (or granular_u8, granular_u16
or whatever it is called) to u32 and be the same as today. Just most
other boxes would benefit.

This actually all assumes that gcc really uses the byte instructions
for byte stores in structures, which is to be determined.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5 / test13-pre7

[Dieter Nützel]

Hello Rik,

I did some more benchmarks on this --- puh, took me some time...:-)

Test machine: 256 MB, K7 550 SlotA, SCSI, IDE, ReiserFS 3.6.23, Blocksize=4K
Test: dbench 48

2.4.0-test13-pre5 + Rik's VM fix #2

/dev/sda7:
 Timing buffered disk reads:  64 MB in  6.07 seconds = 10.54 MB/sec

Throughput 7.54785 MB/sec (NB=9.43482 MB/sec  75.4785 MBit/sec)
41.200u 95.870s 13:59.50 16.3%  0+0k 0+0io 1797pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 7.7981 MB/sec (NB=9.74762 MB/sec  77.981 MBit/sec)
42.180u 96.620s 13:32.54 17.0%  0+0k 0+0io 1799pf+0w

--

/dev/hdc1:
 Timing buffered disk reads:  64 MB in  2.89 seconds = 22.15 MB/sec

Throughput 9.4113 MB/sec (NB=11.7641 MB/sec  94.113 MBit/sec)
36.990u 117.720s 11:13.24 22.9% 0+0k 0+0io 1505pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 10.254 MB/sec (NB=12.8175 MB/sec  102.54 MBit/sec)
36.620u 112.870s 10:17.91 24.1% 0+0k 0+0io 1505pf+0w

***

2.4.0-test13-pre7

/dev/sda7:
 Timing buffered disk reads:  64 MB in  6.07 seconds = 10.54 MB/sec

Throughput 9.61382 MB/sec (NB=12.0173 MB/sec  96.1382 MBit/sec)
43.950u 96.790s 10:59.06 21.3%  0+0k 0+0io 1746pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 10.8312 MB/sec (NB=13.539 MB/sec  108.312 MBit/sec)
44.510u 93.000s 9:44.99 23.5%   0+0k 0+0io 1795pf+0w

-

/dev/hdc1:
 Timing buffered disk reads:  64 MB in  2.89 seconds = 22.15 MB/sec

Throughput 12.3312 MB/sec (NB=15.414 MB/sec  123.312 MBit/sec)
35.220u 112.630s 8:33.83 28.7%  0+0k 0+0io 1505pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 14.4331 MB/sec (NB=18.0414 MB/sec  144.331 MBit/sec)
36.060u 119.760s 7:19.00 35.4%  0+0k 0+0io 1505pf+0w

Addition:
Your fix show some 'bad' swap behavior on my 'normal' load (3D medical 
visualization). It do some 'little' swap out and in. Mostly the (not needed?) 
swap in hurts performance. A little 'cp -a X11R6 X11R6-new' take more than 2 
times longer. If my system hits the 'ZERO swap wall' the currently running 
process (render) abort immediately and restart. With test13-pre7 it runs 
several times longer (render generates some more frames) but then load goes 
up to 10 and render would be killed.

SunWave1>cat /proc/version
Linux version 2.4.0-test13-pre7 (root@SunWave1) (gcc version 2.95.2 19991024 
(release)) #1 Sat Dec 30 22:13:04 CET 2000
SunWave1>free -t
 total   used   free sharedbuffers cached
Mem:255728 164980  90748  0  34160  46488
-/+ buffers/cache:  84332 171396
Swap:   200772  8 200764
Total:  456500 164988 291512

Happy New Year!
I'll be back on Monday.

-Dieter

-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: VIA IDE controller strangeness (2.4.0-test12/test13-pre5)

[Evan Thompson]

--(CC replies please)--

On Sat, Dec 30, 2000 at 06:34:14PM +0100, Matthias Andree wrote:
> Could you report the chip set type and revision? Quote the corresponding
> parts from the "lspci -v" output, please. I've been using PC Chips main
> boards with VIA chip sets without IDE difficulties ever since I bought
> one of those in fall 1998. (VIA Apollo MVP3 AGP, VT82C598 + VT82C586
> north+south bridges), both PC Chips M577 and Tyan Trinity S1590S.

Alrighty then (this is output from lspci -v running under 2.2.18pre21):

-- BEGIN OUTPUT --
...

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA
 [Apollo VP] (rev 41)
Subsystem: VIA Technologies, Inc. MVP3 ISA Bridge
Flags: bus master, stepping, medium devsel, latency 0

00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
 (prog-if 8f [Master SecP SecO PriP PriO])
Flags: bus master, medium devsel, latency 32, IRQ 14
I/O ports at 01f0
I/O ports at 03f4
I/O ports at 0170
I/O ports at 0374
I/O ports at ffa0

...

-- END OUTPUT --

Now...one thing I noticed is that Linux is trying to find this IDE
interface through PCI and it reports it on 00:07.1 during -test12 and
-test13-pre5 boot up (I can't get a dmesg output for you 'cause it never
boots...just keeps complaining about hdb: lost interrupt), but the IDE
controller seems to be an ISA device (unless I've read this wrong).
In case I'm configuring something wrong, I've pasted the IDE .config
portions here:

CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
ONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y

Hope this stuff helps you guys out.
If somebody wants to tell me a better way to get nvi to wrap lines at 75
chars (other than hitting enter when I think it has to be hit), you could
e-mail me (don't bother sending it to the list).

CC replies please.  I don't subscribe to linux-kernel.  Sorry.
-- 
| Evan A. Thompson | He's more fun than trying to skinny  | 
| [EMAIL PROTECTED]   | dip in the beach in winter...|
| http://evaner.penguinpowered.com |...in Winnipeg.   |
| ICQ: 2233067 / AIM + MSN: Evaner517  |  (GnuPG key avaiable upon request.)  |

...hmmm...Now I'm going to have to adjust my .signature to fit in 75
chars instead of 79.  Darn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: VIA IDE controller strangeness (2.4.0-test12/test13-pre5)

[Matthias Andree]

On Fri, 29 Dec 2000, Evan Thompson wrote:

> ---(CC answer please)---

To: should be fine as well, I assume.

> I'm having a strange problem with my IDE controller.  I believe (and
> that's what Windows and the m/b manufaturer -- PC Chips -- say) that I
> have a VIA PCI BusMaster IDE controller, and I've had some strange
> history with it.  I've asked many people before on various help
> services, and I was able to fix my problem with the 2.2 series, but
> now my fix does not work.
> 
> THE PROBLEM: 
> 
> Ever since the 2.2 kernel series (I remeber this working properly in
> 2.0.36, without the conflicts), I would get hdc: lost interrupt during
> boot up, and my system would take bloody ages to boot up and load a
> CD.  I tracked it down to a strange IRQ conflict in which Linux would
> try to assign both the primary and secondary IDE channels IRQ 14,
> causing IRQ conflicts galore.  I was able to fix this by giving the
> kernel
> 
> ide1=0x170,0x376,15
> 
> at boot time.  This has worked for 2.2.12-.17 and Alan's 2.2.18pre21
> (I haven't compiled the official 2.2.18 yet, but I'm sure it will
> work).

Could you report the chip set type and revision? Quote the corresponding
parts from the "lspci -v" output, please. I've been using PC Chips main
boards with VIA chip sets without IDE difficulties ever since I bought
one of those in fall 1998. (VIA Apollo MVP3 AGP, VT82C598 + VT82C586
north+south bridges), both PC Chips M577 and Tyan Trinity S1590S.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: VIA IDE controller strangeness (2.4.0-test12/test13-pre5)

[Matthias Andree]

On Fri, 29 Dec 2000, Evan Thompson wrote:

 ---(CC answer please)---

To: should be fine as well, I assume.

 I'm having a strange problem with my IDE controller.  I believe (and
 that's what Windows and the m/b manufaturer -- PC Chips -- say) that I
 have a VIA PCI BusMaster IDE controller, and I've had some strange
 history with it.  I've asked many people before on various help
 services, and I was able to fix my problem with the 2.2 series, but
 now my fix does not work.
 
 THE PROBLEM: 
 
 Ever since the 2.2 kernel series (I remeber this working properly in
 2.0.36, without the conflicts), I would get hdc: lost interrupt during
 boot up, and my system would take bloody ages to boot up and load a
 CD.  I tracked it down to a strange IRQ conflict in which Linux would
 try to assign both the primary and secondary IDE channels IRQ 14,
 causing IRQ conflicts galore.  I was able to fix this by giving the
 kernel
 
 ide1=0x170,0x376,15
 
 at boot time.  This has worked for 2.2.12-.17 and Alan's 2.2.18pre21
 (I haven't compiled the official 2.2.18 yet, but I'm sure it will
 work).

Could you report the chip set type and revision? Quote the corresponding
parts from the "lspci -v" output, please. I've been using PC Chips main
boards with VIA chip sets without IDE difficulties ever since I bought
one of those in fall 1998. (VIA Apollo MVP3 AGP, VT82C598 + VT82C586
north+south bridges), both PC Chips M577 and Tyan Trinity S1590S.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: VIA IDE controller strangeness (2.4.0-test12/test13-pre5)

[Evan Thompson]

--(CC replies please)--

On Sat, Dec 30, 2000 at 06:34:14PM +0100, Matthias Andree wrote:
 Could you report the chip set type and revision? Quote the corresponding
 parts from the "lspci -v" output, please. I've been using PC Chips main
 boards with VIA chip sets without IDE difficulties ever since I bought
 one of those in fall 1998. (VIA Apollo MVP3 AGP, VT82C598 + VT82C586
 north+south bridges), both PC Chips M577 and Tyan Trinity S1590S.

Alrighty then (this is output from lspci -v running under 2.2.18pre21):

-- BEGIN OUTPUT --
...

00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA
 [Apollo VP] (rev 41)
Subsystem: VIA Technologies, Inc. MVP3 ISA Bridge
Flags: bus master, stepping, medium devsel, latency 0

00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
 (prog-if 8f [Master SecP SecO PriP PriO])
Flags: bus master, medium devsel, latency 32, IRQ 14
I/O ports at 01f0
I/O ports at 03f4
I/O ports at 0170
I/O ports at 0374
I/O ports at ffa0

...

-- END OUTPUT --

Now...one thing I noticed is that Linux is trying to find this IDE
interface through PCI and it reports it on 00:07.1 during -test12 and
-test13-pre5 boot up (I can't get a dmesg output for you 'cause it never
boots...just keeps complaining about hdb: lost interrupt), but the IDE
controller seems to be an ISA device (unless I've read this wrong).
In case I'm configuring something wrong, I've pasted the IDE .config
portions here:

CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
ONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_IDEDMA_AUTO=y
CONFIG_BLK_DEV_IDE_MODES=y

Hope this stuff helps you guys out.
If somebody wants to tell me a better way to get nvi to wrap lines at 75
chars (other than hitting enter when I think it has to be hit), you could
e-mail me (don't bother sending it to the list).

CC replies please.  I don't subscribe to linux-kernel.  Sorry.
-- 
| Evan A. Thompson | He's more fun than trying to skinny  | 
| [EMAIL PROTECTED]   | dip in the beach in winter...|
| http://evaner.penguinpowered.com |...in Winnipeg.   |
| ICQ: 2233067 / AIM + MSN: Evaner517  |  (GnuPG key avaiable upon request.)  |

...hmmm...Now I'm going to have to adjust my .signature to fit in 75
chars instead of 79.  Darn.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5 / test13-pre7

[Dieter Nützel]

Hello Rik,

I did some more benchmarks on this --- puh, took me some time...:-)

Test machine: 256 MB, K7 550 SlotA, SCSI, IDE, ReiserFS 3.6.23, Blocksize=4K
Test: dbench 48

2.4.0-test13-pre5 + Rik's VM fix #2

/dev/sda7:
 Timing buffered disk reads:  64 MB in  6.07 seconds = 10.54 MB/sec

Throughput 7.54785 MB/sec (NB=9.43482 MB/sec  75.4785 MBit/sec)
41.200u 95.870s 13:59.50 16.3%  0+0k 0+0io 1797pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 7.7981 MB/sec (NB=9.74762 MB/sec  77.981 MBit/sec)
42.180u 96.620s 13:32.54 17.0%  0+0k 0+0io 1799pf+0w

--

/dev/hdc1:
 Timing buffered disk reads:  64 MB in  2.89 seconds = 22.15 MB/sec

Throughput 9.4113 MB/sec (NB=11.7641 MB/sec  94.113 MBit/sec)
36.990u 117.720s 11:13.24 22.9% 0+0k 0+0io 1505pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 10.254 MB/sec (NB=12.8175 MB/sec  102.54 MBit/sec)
36.620u 112.870s 10:17.91 24.1% 0+0k 0+0io 1505pf+0w

***

2.4.0-test13-pre7

/dev/sda7:
 Timing buffered disk reads:  64 MB in  6.07 seconds = 10.54 MB/sec

Throughput 9.61382 MB/sec (NB=12.0173 MB/sec  96.1382 MBit/sec)
43.950u 96.790s 10:59.06 21.3%  0+0k 0+0io 1746pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 10.8312 MB/sec (NB=13.539 MB/sec  108.312 MBit/sec)
44.510u 93.000s 9:44.99 23.5%   0+0k 0+0io 1795pf+0w

-

/dev/hdc1:
 Timing buffered disk reads:  64 MB in  2.89 seconds = 22.15 MB/sec

Throughput 12.3312 MB/sec (NB=15.414 MB/sec  123.312 MBit/sec)
35.220u 112.630s 8:33.83 28.7%  0+0k 0+0io 1505pf+0w

-O -mcpu=k6 -mpreferred-stack-boundary=2 -malign-functions=4
-fschedule-insns2 -fexpensive-optimizations

Throughput 14.4331 MB/sec (NB=18.0414 MB/sec  144.331 MBit/sec)
36.060u 119.760s 7:19.00 35.4%  0+0k 0+0io 1505pf+0w

Addition:
Your fix show some 'bad' swap behavior on my 'normal' load (3D medical 
visualization). It do some 'little' swap out and in. Mostly the (not needed?) 
swap in hurts performance. A little 'cp -a X11R6 X11R6-new' take more than 2 
times longer. If my system hits the 'ZERO swap wall' the currently running 
process (render) abort immediately and restart. With test13-pre7 it runs 
several times longer (render generates some more frames) but then load goes 
up to 10 and render would be killed.

SunWave1cat /proc/version
Linux version 2.4.0-test13-pre7 (root@SunWave1) (gcc version 2.95.2 19991024 
(release)) #1 Sat Dec 30 22:13:04 CET 2000
SunWave1free -t
 total   used   free sharedbuffers cached
Mem:255728 164980  90748  0  34160  46488
-/+ buffers/cache:  84332 171396
Swap:   200772  8 200764
Total:  456500 164988 291512

Happy New Year!
I'll be back on Monday.

-Dieter

-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: PATCH: test13-pre5/drivers/sound/via82cxxx_audio.c did notcompile

[Linus Torvalds]

On Fri, 29 Dec 2000, Adam J. Richter wrote:
>
>   linux-2.4.0-test13-pre5 eliminated vm_operations_struct->swapout,
> but this change was not reflected in drivers/sound/via82cxxx_audio.c,
> causing that file to fail to compile.  I have attached what I believe
> is the correct fix below.

Actually, the right fix is to change all VM_RESERVE to VM_RESERVED (ie add
a "D" at the end), at which point it should compile and work fine..

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PATCH: test13-pre5/drivers/sound/via82cxxx_audio.c did not compile

[Adam J. Richter]

linux-2.4.0-test13-pre5 eliminated vm_operations_struct->swapout,
but this change was not reflected in drivers/sound/via82cxxx_audio.c,
causing that file to fail to compile.  I have attached what I believe
is the correct fix below.

via82cxxx_audio.c has Jeff Garzik's name on it, but I understand
that he is taking a break for a few weeks to recover from typing strain.
(Hope you recover soon, Jeff.)  Consequently, I am not sure whom I should
ask to "bless" this change.  So, I'll just send this to linux-kernel
and Linus and will leave it to linux-kernel readers to sound the alarm
if I botched the patch.

-- 
Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."


--- linux-2.4.0-test13-pre5/drivers/sound/via82cxxx_audio.c Mon Oct 30 12:24:22 
2000
+++ linux/drivers/sound/via82cxxx_audio.c   Fri Dec 29 16:53:22 2000
@@ -1727,20 +1727,8 @@
 }
 
 
-#ifndef VM_RESERVE
-static int via_mm_swapout (struct page *page, struct file *filp)
-{
-   return 0;
-}
-#endif /* VM_RESERVE */
-
-
 struct vm_operations_struct via_mm_ops = {
nopage: via_mm_nopage,
-
-#ifndef VM_RESERVE
-   swapout:via_mm_swapout,
-#endif
 };
 
 

(REPOST-sorry) PCI VIA IDE Strangeness w/2.4.0-test12/test13-pre5

[Evan Thompson]

REPOST: People have asked me to repost this message because their e-mail clients
don't wrap lines.  I'd like to know which ones don't, but this isn't the list
for that kind of question, unless it is, which then means I'm posting to the
wrong list to start with and then I wouldn't have to repost.  Anyways...

---(CC answer please)---

I'm having a strange problem with my IDE controller.  I believe (and that's
what Windows and the m/b manufaturer -- PC Chips -- say) that I have a VIA PCI
BusMaster IDE controller, and I've had some strange history with it.  I've
asked many people before on various help services, and I was able to fix my
problem with the 2.2 series, but now my fix does not work.

THE PROBLEM:


Ever since the 2.2 kernel series (I remeber this working properly in 2.0.36,
without the conflicts), I would get hdc: lost interrupt during boot up, and my
system would take bloody ages to boot up and load a CD.  I tracked it down to a
strange IRQ conflict in which Linux would try to assign both the primary and
secondary IDE channels IRQ 14, causing IRQ conflicts galore.  I was able to fix
this by giving the kernel

ide1=0x170,0x376,15

at boot time.  This has worked for 2.2.12-.17 and Alan's 2.2.18pre21 (I haven't
compiled the official 2.2.18 yet, but I'm sure it will work).

I wanted to try the new 2.4.0-test series, and the first I tried was -test11,
and from what I recall (other things weren't working properly then), this fix
still worked, but now, with -test12, I am now getting the following error
repeated for a very long time (then I reboot) with the same parameters:

ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
hdb: lost interrupt

Also, I get "spurious 8259A interrupt: IRQ 7" if I leave it for a while.  I
tried -test13-pre5 on somebody on #KernelNewbies' suggestion, and I get the
same error.  Scrolling up, I see that the kernel messages show that ide0 is on
IRQ 14 and ide1 is on 15.  I noticed that hda is using DMA, and hdb is using
UDMA33, but I don't believe that that is the problem.

THE QUESTION:
-

How do I fix this, or is it a (un)known problem in the newer development
versions?  If you have the answer, could you please CC me as well for I don't
subscribe to this mailing list (sorry!).  Thanks a bunch.
-- 
| Evan A. Thompson | He's more fun than trying to skinny  | 
| [EMAIL PROTECTED]   | dip in the beach in winter...|
| http://evaner.penguinpowered.com |...in Winnipeg.   |
| ICQ: 2233067 / AIM + MSN: Evaner517  |  (GnuPG key avaiable upon request.)  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Dieter Nützel]

Am Freitag, 29. Dezember 2000 14:38 schrieben Sie:
> On Fri, 29 Dec 2000, Dieter Nützel wrote:
> > your patch didn't apply clean.
> > Have you another version?
>
> It should apply just fine. What error messages did
> patch give ?
>
Applied #2 against my running 2.4.0-test13-pre5 + ReiserFS 3.6.23 tree and
a clean test13-pre5 (test12 + test13-pre5). Same for both of them:

SunWave1>patch -p0 -E -N http://www.tux.org/lkml/

Re: [PATCH] i810 audio fixes for 2.4.0-test13-pre5

[Alan Cox]

> This patch addresses three problems in the i810-audio driver for
> 2.4.0-test13-pre5.  I will be happy to split it if someone doesn't like
> part of it.  (I see pre6 just popped out, there are no changes to this
> driver in pre6.)

> 1) "DMA overrun on send" - this contains a patch from Tjeerd Mulder that
>prevents almost all of this.  I still get an occasional one during
>heavy video activity, the driver was unusable before.  (This is a smaller 
>patch than the previous flamed patch, it does no format conversion.)

Yeah I have Tjeerd's patches and no quibbles with them

> 3) Add a module parameter to supress powercycling the DACs on rate change -
>This causes a big pop on the outputs at least for the CS4299 codec in
>the emachines etower 700, probably others.  I honestly can't find a 
>reason to power cycle the DACs.  There's nothing in the AC97 spec 
>that suggests it should be done.  The code is common to OSS and ALSA.
>I left the old behavior as the default.  Maybe later the default should
>change if it turns out that everyone wants to force the parameter to 
>zero.

What I would love someone to do (hint ;)) is to move the 

set_dac_speed
set_adc_speed
powerup_amp
powerdown_amp

type stuff into the ac97_codec - actually have a codec_ops in the AC97 
for each type.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

VIA IDE controller strangeness (2.4.0-test12/test13-pre5)

[Evan Thompson]

---(CC answer please)---

I'm having a strange problem with my IDE controller.  I believe (and that's what 
Windows and the m/b manufaturer -- PC Chips -- say) that I have a VIA PCI BusMaster 
IDE controller, and I've had some strange history with it.  I've asked many people 
before on various help services, and I was able to fix my problem with the 2.2 series, 
but now my fix does not work.

THE PROBLEM:


Ever since the 2.2 kernel series (I remeber this working properly in 2.0.36, without 
the conflicts), I would get hdc: lost interrupt during boot up, and my system would 
take bloody ages to boot up and load a CD.  I tracked it down to a strange IRQ 
conflict in which Linux would try to assign both the primary and secondary IDE 
channels IRQ 14, causing IRQ conflicts galore.  I was able to fix this by giving the 
kernel

ide1=0x170,0x376,15

at boot time.  This has worked for 2.2.12-.17 and Alan's 2.2.18pre21 (I haven't 
compiled the official 2.2.18 yet, but I'm sure it will work).

I wanted to try the new 2.4.0-test series, and the first I tried was -test11, and from 
what I recall (other things weren't working properly then), this fix still worked, but 
now, with -test12, I am now getting the following error repeated for a very long time 
(then I reboot) with the same parameters:

ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
hdb: lost interrupt

Also, I get "spurious 8259A interrupt: IRQ 7" if I leave it for a while.  I tried 
-test13-pre5 on somebody on #KernelNewbies' suggestion, and I get the same error.  
Scrolling up, I see that the kernel messages show that ide0 is on IRQ 14 and ide1 is 
on 15.  I noticed that hda is using DMA, and hdb is using UDMA33, but I don't believe 
that that is the problem.

THE QUESTION:
-

How do I fix this, or is it a (un)known problem in the newer development versions?  If 
you have the answer, could you please CC me as well for I don't subscribe to this 
mailing list (sorry!).  Thanks a bunch.
-- 
| Evan A. Thompson | He's more fun than trying to skinny  | 
| [EMAIL PROTECTED]   | dip in the beach in winter...|
| http://evaner.penguinpowered.com |...in Winnipeg.   |
| ICQ: 2233067 / AIM + MSN: Evaner517  |  (GnuPG key avaiable upon request.)  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] i810 audio fixes for 2.4.0-test13-pre5

[Jim Studt]

This patch addresses three problems in the i810-audio driver for
2.4.0-test13-pre5.  I will be happy to split it if someone doesn't like
part of it.  (I see pre6 just popped out, there are no changes to this
driver in pre6.)

1) "DMA overrun on send" - this contains a patch from Tjeerd Mulder that
   prevents almost all of this.  I still get an occasional one during
   heavy video activity, the driver was unusable before.  (This is a smaller 
   patch than the previous flamed patch, it does no format conversion.)

2) Enable codec rate adaption - the current rate setting functions attempt 
   to get the codecs to rate adapt, but neglect to turn on the bit in the
   "Extended Audio Status and Control Register" that allows the codec to 
   actually adapt.  (Audio Codec '97, Rev 2.2, Intel, section 5.8.2)
   This allows audio of other than 48kHz if the codec supports it.

3) Add a module parameter to supress powercycling the DACs on rate change -
   This causes a big pop on the outputs at least for the CS4299 codec in
   the emachines etower 700, probably others.  I honestly can't find a 
   reason to power cycle the DACs.  There's nothing in the AC97 spec 
   that suggests it should be done.  The code is common to OSS and ALSA.
   I left the old behavior as the default.  Maybe later the default should
   change if it turns out that everyone wants to force the parameter to 
   zero.

After this is applied I will followup with another patch that 
adds /proc/driver/i810-audio/... support like the via82cxxx driver.
I don't know is user's need it, but it sure helps debugging and 
figuring out what sort of hardware is really in the computer.




--- clean-linux/drivers/sound/i810_audio.c  Wed Nov  8 19:09:50 2000
+++ linux/drivers/sound/i810_audio.cFri Dec 29 18:10:19 2000
@@ -102,6 +102,7 @@
 
 static int ftsodell=0;
 static unsigned int clocking=48000;
+static int cycle_power=1;
 
 
 #define ADC_RUNNING1
@@ -382,7 +383,7 @@
 static unsigned int i810_set_dac_rate(struct i810_state * state, unsigned int rate)
 {  
struct dmabuf *dmabuf = >dmabuf;
-   u32 dacp;
+   u32 dacp=0;
struct ac97_codec *codec=state->card->ac97_codec[0];

if(!(state->card->ac97_features&0x0001))
@@ -410,14 +411,23 @@
 
if(rate != i810_ac97_get(codec, AC97_PCM_FRONT_DAC_RATE))
{
+   u16 extended_status = i810_ac97_get(codec, AC97_EXTENDED_STATUS);
+
+   /* enable variable rate audio */
+   if ( !(extended_status&1)) {
+   i810_ac97_set(codec, AC97_EXTENDED_STATUS, extended_status | 
+1);
+   }
+
/* Power down the DAC */
-   dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
-   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0200);
+   if ( cycle_power) {
+   dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
+   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0200);
+   }
/* Load the rate and read the effective rate */
i810_ac97_set(codec, AC97_PCM_FRONT_DAC_RATE, rate);
rate=i810_ac97_get(codec, AC97_PCM_FRONT_DAC_RATE);
/* Power it back up */
-   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
+   if ( cycle_power) i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
}
rate=(rate * 48000) / clocking;
dmabuf->rate = rate;
@@ -432,7 +442,7 @@
 static unsigned int i810_set_adc_rate(struct i810_state * state, unsigned int rate)
 {
struct dmabuf *dmabuf = >dmabuf;
-   u32 dacp;
+   u32 dacp=0;
struct ac97_codec *codec=state->card->ac97_codec[0];

if(!(state->card->ac97_features&0x0001))
@@ -460,14 +470,22 @@
 
if(rate != i810_ac97_get(codec, AC97_PCM_LR_DAC_RATE))
{
+   u16 extended_status = i810_ac97_get(codec, AC97_EXTENDED_STATUS);
+   /* enable variable rate audio */
+   if ( !(extended_status&1)) {
+   i810_ac97_set(codec, AC97_EXTENDED_STATUS, extended_status | 
+1);
+   }
+
/* Power down the ADC */
-   dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
-   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0100);
+   if ( cycle_power) {
+   dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
+   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0100);
+   }
/* Load the rate and read the effective rate */
i810_ac97_set(codec, AC97_PCM_LR_DAC_RATE, rate);
rate=i810_ac97_get(codec, AC97_PCM_LR_DAC_RATE);
/* Power it back up */
-   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
+   if ( cycle_power) i810_ac97_set(codec, AC97_POW

Re: test13-pre5 + char-major-145??

[Keith Owens]

On Fri, 29 Dec 2000 14:07:57 -0700, 
Frank Jacobberger <[EMAIL PROTECTED]> wrote:
>modprobe: Can't locate module char-major-145
>
>From /usr/src/linux/Documentation/devices.txt
>
>10 charNon-serial mice, misc features
>145 = /dev/hfmodem  Soundcard shortwave modem control {2.6}

That is major 10, minor 145.  Search /145 *char/ to find char-major-145.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Fri, 29 Dec 2000, David S. Miller wrote:
> 
>  For my development testing, I'm running a _heavily_ hacked
>kernel.  One of these hacks is to pull the wait_queue_head out of
>struct page; the waitq-heads are in a separate allocated area of
>memory, with a waitq-head pointer embedded in the page structure
>(allocated/initialised in free_area_init_core()).  This gives a
>page structure of 60bytes, giving me one free double-word to play
>with (which I'm using as a pointer to a release function).
> 
> Not something like those damn Solaris turnstiles, no please

If you want to have a release function, please just use "page->mapping",
which gives you much more, including memory pressure indicators etc. Now
_that_ can be useful for doing things like slab caches.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[David S. Miller]

   Date: Fri, 29 Dec 2000 15:46:22 + (GMT)
   From: Mark Hemment <[EMAIL PROTECTED]>

 For my development testing, I'm running a _heavily_ hacked
   kernel.  One of these hacks is to pull the wait_queue_head out of
   struct page; the waitq-heads are in a separate allocated area of
   memory, with a waitq-head pointer embedded in the page structure
   (allocated/initialised in free_area_init_core()).  This gives a
   page structure of 60bytes, giving me one free double-word to play
   with (which I'm using as a pointer to a release function).

Not something like those damn Solaris turnstiles, no please

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5 + char-major-145??

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> What may be calling this? Any advice where to go ferreting?

Somebody may try to open the device file.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

test13-pre5 + char-major-145??

[Frank Jacobberger]

Please help me explain why I'm getting the following
modprobe reply on boot up after kernel test13-pre5
loads:

modprobe: Can't locate module char-major-145

>From /usr/src/linux/Documentation/devices.txt

10 charNon-serial mice, misc features
145 = /dev/hfmodem  Soundcard shortwave modem control {2.6}

My modules.conf:
---
alias eth0 rtl8139
alias eth1 rtl8139
alias parport_lowlevel parport_pc
alias sound-slot-0 emu10k1
alias usb-controller usb-uhci
---

What may be calling this? Any advice where to go ferreting?

Thanks,

Frank

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] #2 VM fixes + RSS limits 2.4.0-test13-pre5 #2

[Rik van Riel]

Hi Linus, Alan,

Here is a second version of my patch ... it turned out that
fixing of the return value of try_to_swap_out() means that
swap_out_mm() doesn't unlock the mm->page_table_lock ...

The reason I didn't run into this bug yesterday was that the
RSS trimming took care of all the swapout I needed. ;)

The (small) fixes wrt. yesterday's patch are added below.

> 1. trivially implement RSS ulimit support, with
>p->rlim[RLIMIT_RSS].rlim_max treated as a hard limit
>and .rlim_cur treated as a soft limit

1a.  don't call enforce_rss_limit() while we're holding the
 tasklist_lock ...

1b.  enforce_rss_limit() now loops a few times if the first
 scanning of the RSS didn't bring us under the soft limit

 this turned out to be needed in order to bring a task
 down to its RSS limit if the working set is bigger and
 there is no VM pressure ... whether it is good or not to
 trim to smaller than the working set I don't know, though ;))

> 2. fix the return value from try_to_swap_out() to return
>success whenever we make the RSS of a process smaller

2a.  fix swap_out_mm() to unlock the mm->page_table_lock
 on success as well

> 3. clean up refill_inactive() ... try_to_swap_out() returns
>the expected result now, so things should be balanced again
> 
> 4. only call deactivate_page() from generic_file_write() if we
>write "beyond the end of" the page, so partially written
>pages stay active and will remain in memory longer (8% more
>performance for dbench, as tested by Daniel Phillips)
> 
> 5. (minor) s/unsigned int gfp_mask/int gfp_mask/ in vmscan.c
>... we had both types used, which is rather inconsistent
> 
> Please consider including this patch in the next 2.4 pre-patch,
> IMHO all of these things are fairly trivial and it seems to run
> very nicely on my test box ;)

The request for inclusion still stands ... I'll be stress-testing
my test machine all weekend while I'm away on the beach.

Other testers are requested ... how does this perform on your
machine and/or are you able to hang it?  (I guess the patch
is simple enough to not have any influence on stability)

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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



--- linux-2.4.0-test13-pre5/mm/filemap.c.orig   Thu Dec 28 19:11:39 2000
+++ linux-2.4.0-test13-pre5/mm/filemap.cThu Dec 28 19:28:06 2000
@@ -1912,7 +1912,7 @@
 
/* Make sure this doesn't exceed the process's max rss. */
error = -EIO;
-   rlim_rss = current->rlim ?  current->rlim[RLIMIT_RSS].rlim_cur :
+   rlim_rss = current->rlim ?  (current->rlim[RLIMIT_RSS].rlim_cur >> PAGE_SHIFT) 
+:
LONG_MAX; /* default: see resource.h */
if ((vma->vm_mm->rss + (end - start)) > rlim_rss)
return error;
@@ -2438,7 +2438,7 @@
}
 
while (count) {
-   unsigned long bytes, index, offset;
+   unsigned long bytes, index, offset, partial = 0;
char *kaddr;
 
/*
@@ -2448,8 +2448,10 @@
offset = (pos & (PAGE_CACHE_SIZE -1)); /* Within page */
index = pos >> PAGE_CACHE_SHIFT;
bytes = PAGE_CACHE_SIZE - offset;
-   if (bytes > count)
+   if (bytes > count) {
bytes = count;
+   partial = 1;
+   }
 
/*
 * Bring in the user page that we will copy from _first_.
@@ -2491,9 +2493,17 @@
buf += status;
}
 unlock:
-   /* Mark it unlocked again and drop the page.. */
+   /*
+* Mark it unlocked again and release the page.
+* In order to prevent large (fast) file writes
+* from causing too much memory pressure we move
+* completely written pages to the inactive list.
+* We do, however, try to keep the pages that may
+* still be written to (ie. partially written pages).
+*/
UnlockPage(page);
-   deactivate_page(page);
+   if (!partial)
+   deactivate_page(page);
page_cache_release(page);
 
        if (status < 0)
--- linux-2.4.0-test13-pre5/mm/memory.c.origThu Dec 28 19:11:39 2000
+++ linux-2.4.0-test13-pre5/mm/memory.c Fri Dec 29 17:10:53 2000
@@ -1198,6 +1198,12 @@
pgd = pgd_offset(mm, address);
pmd = pmd_alloc(pgd, address);
 
+   if (mm->rss >= (current->rlim[RLIMIT_RSS].rlim_max >> PAGE_SHIFT)) {
+   lock_kernel();
+   enforce_rss_limit(current, GFP_HIGHUSER);
+   unlock_kernel

test13-pre5 and 8139too

[Jacobberger Mark]

I'm getting intermittent time out on my
Realtek 8139B - 8139too on eth0

Guess the problems back.

Fun..., Have to reboot my Cisco 675 

Oh well...

Frank

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Tom Rini]

On Thu, Dec 28, 2000 at 12:25:23PM -0800, Linus Torvalds wrote:

>  - pre5:
>- NIIBE Yutaka: SuperH update
>- Geert Uytterhoeven: m68k update
>- David Miller: TCP RTO calc fix, UDP multicast fix etc
>- Duncan Laurie: ServerWorks PIRQ routing definition.
>- mm PageDirty cleanups, added sanity checks, and don't lose the bit. 

I just noticed this (playing with some other stuff), but ext2 as a module
is currently broken:
$ make INSTALL_MOD_PATH=/tmp/foo modules_install
...
if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b /tmp/foo -r 2.4.0-test12; 
fi
depmod: *** Unresolved symbols in 
/tmp/foo/lib/modules/2.4.0-test12/kernel/fs/ext2/ext2.o
depmod: buffer_insert_inode_queue
depmod: fsync_inode_buffers

I tried the following locally and it fixes it.
--
--- fs/Makefile.origFri Dec 29 10:35:50 2000
+++ fs/Makefile Fri Dec 29 10:36:06 2000
@@ -7,7 +7,7 @@
 
 O_TARGET := fs.o
 
-export-objs := filesystems.o
+export-objs := filesystems.o buffer.o
 mod-subdirs := nls
 
 obj-y :=   open.o read_write.o devices.o file_table.o buffer.o \
--- fs/buffer.c.origFri Dec 29 10:33:21 2000
+++ fs/buffer.c Fri Dec 29 10:35:46 2000
@@ -29,6 +29,7 @@
 /* async buffer flushing, 1999 Andrea Arcangeli <[EMAIL PROTECTED]> */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -579,6 +580,8 @@
spin_unlock(_list_lock);
 }
 
+EXPORT_SYMBOL(buffer_insert_inode_queue);
+
 /* The caller must have the lru_list lock before calling the 
remove_inode_queue functions.  */
 static void __remove_inode_queue(struct buffer_head *bh)
@@ -900,6 +903,7 @@
return err2;
 }
 
+EXPORT_SYMBOL(fsync_inode_buffers);
 
 /*
  * osync is designed to support O_SYNC io.  It waits synchronously for
--

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Mark Hemment]

On Fri, 29 Dec 2000, Tim Wright wrote:
> Yes, this is a very important point if we ever want to make serious use
> of large memory machines on ia32. We ran into this with DYNIX/ptx when the
> P6 added 36-bit physical addressing. Conserving KVA (kernel virtual address
> space), became a very high priority. Eventually, we had to add code to play
> silly segment games and "magically" materialize and dematerialize a 4GB
> kernel virtual address space instead of the 1GB. This only comes into play
> with really large amounts of memory, and is almost certainly not worth the
> agony of implementation on Linux, but we'll need to be careful elsewhere to
> conserve it as much as possible.

  Indeed.  I'm compiling my kernels with 2GB virtual.  Not as I want more
NORMAL pages in the page cache (HIGH memory is fine), but as I need
NORMAL pages for kernel data/structures (memory allocated from  
slab-caches) which need to be constantly mapped in.

Mark


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Tim Wright]

On Fri, Dec 29, 2000 at 03:46:22PM +, Mark Hemment wrote:
>   Note, for those of us running on 32bit with lots of physical memory, the
> available virtual address-space is of major consideration.  Reducing the
> size of the page structure is more than just reducing cache misses - it
> gives us more virtual to play with...
> 
> Mark
> 

Yes, this is a very important point if we ever want to make serious use
of large memory machines on ia32. We ran into this with DYNIX/ptx when the
P6 added 36-bit physical addressing. Conserving KVA (kernel virtual address
space), became a very high priority. Eventually, we had to add code to play
silly segment games and "magically" materialize and dematerialize a 4GB
kernel virtual address space instead of the 1GB. This only comes into play
with really large amounts of memory, and is almost certainly not worth the
agony of implementation on Linux, but we'll need to be careful elsewhere to
conserve it as much as possible.

Regards,

Tim


-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Mark Hemment]

Hi,

On Thu, 28 Dec 2000, David S. Miller wrote:
>Date:  Thu, 28 Dec 2000 23:17:22 +0100
>From: Andi Kleen <[EMAIL PROTECTED]>
> 
>Would you consider patches for any of these points? 
> 
> To me it seems just as important to make sure struct page is
> a power of 2 in size, with the waitq debugging turned off this
> is true for both 32-bit and 64-bit hosts last time I checked.

  Checking test11 (which I'm running here), even with waitq debugging
turned off, on 32-bit (IA32) the struct page is 68bytes (since
the "age" member was re-introduced a while back).

  For my development testing, I'm running a _heavily_ hacked kernel.  One
of these hacks is to pull the wait_queue_head out of struct page; the
waitq-heads are in a separate allocated area of memory, with a waitq-head
pointer embedded in the page structure (allocated/initialised in
free_area_init_core()).  This gives a page structure of 60bytes, giving me
one free double-word to play with (which I'm using as a pointer to a
release function).

  Infact, there doesn't need to be a waitq-head allocated for each page
structure - they can share; with a performance overhead on a false
wakeup in __wait_on_page().
  Note, for those of us running on 32bit with lots of physical memory, the
available virtual address-space is of major consideration.  Reducing the
size of the page structure is more than just reducing cache misses - it
gives us more virtual to play with...

Mark

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Stefan Traby]

On Fri, Dec 29, 2000 at 01:06:30AM +, Albert Cranford wrote:
> Simply executing
>  *p++ = htonl(fl->fl_pid);
> before 
>  start = loff_t_to_s64(fl->fl_start);
> also works.

Yes, confirmed.
Since you're located in Florida I vote for this and I hope that
Linus will elect it. :)


--- linux/fs/lockd/xdr4.c.orig  Fri Dec 29 01:35:32 2000
+++ linux/fs/lockd/xdr4.c   Fri Dec 29 14:56:07 2000
@@ -167,13 +167,13 @@
 || (fl->fl_end > NLM4_OFFSET_MAX && fl->fl_end != OFFSET_MAX))
return NULL;
 
+   *p++ = htonl(fl->fl_pid);
start = loff_t_to_s64(fl->fl_start);
if (fl->fl_end == OFFSET_MAX)
len = 0;
else
len = loff_t_to_s64(fl->fl_end - fl->fl_start + 1);
 
-   *p++ = htonl(fl->fl_pid);
p = xdr_encode_hyper(p, start);
p = xdr_encode_hyper(p, len);

-- 

  ciao - 
Stefan

"export PS1="rms# "  "

Stefan TrabyLinux/ia32   fax:  +43-3133-6107-9
Mitterlasznitzstr. 13   Linux/alphaphone:  +43-3133-6107-2
8302 Nestelbach Linux/sparc   http://www.hello-penguin.com
Austriamailto:[EMAIL PROTECTED]
Europe   mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

test13-pre5: Double flush_cache_page?

[Russell King]

Hi,

Is the following really intentional?

vmscan.c:122:

flush_cache_page(vma, address);
if (!pte_dirty(pte))
goto drop_pte;
...
flush_cache_page(vma, address);
if (page->mapping) {

Nothing accesses the actual page between the two flush_cache_page() calls,
the first one was added in test13-pre5.  Should test13-pre5 have removed
the second instance?
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Daniel Phillips]

Marcelo Tosatti wrote:
> 
> On Thu, 28 Dec 2000, Linus Torvalds wrote:
> 
> >  - make "SetPageDirty()" do something like
> >
> >   if (!test_and_set(PG_dirty, >flags)) {
> >   spin_lock(_cache_lock);
> >   list_del(page->list);
> >   list_add(page->list, page->mapping->dirty_pages);
> >   spin_unlock(_cache_lock);
> >   }
> 
> We also want to move the page to the per-address-space clean list in
> ClearPageDirty I suppose.

I'd like to suggest taking this opportunity to regularize the notation
by going to set_page_dirty/clear_page_dirty which will call
SetPageDirty/ClearPageDirty.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Daniel Phillips]

Marcelo Tosatti wrote:
 
 On Thu, 28 Dec 2000, Linus Torvalds wrote:
 
   - make "SetPageDirty()" do something like
 
if (!test_and_set(PG_dirty, page-flags)) {
spin_lock(page_cache_lock);
list_del(page-list);
list_add(page-list, page-mapping-dirty_pages);
spin_unlock(page_cache_lock);
}
 
 We also want to move the page to the per-address-space clean list in
 ClearPageDirty I suppose.

I'd like to suggest taking this opportunity to regularize the notation
by going to set_page_dirty/clear_page_dirty which will call
SetPageDirty/ClearPageDirty.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

test13-pre5: Double flush_cache_page?

[Russell King]

Hi,

Is the following really intentional?

vmscan.c:122:

flush_cache_page(vma, address);
if (!pte_dirty(pte))
goto drop_pte;
...
flush_cache_page(vma, address);
if (page-mapping) {

Nothing accesses the actual page between the two flush_cache_page() calls,
the first one was added in test13-pre5.  Should test13-pre5 have removed
the second instance?
   _
  |_| - ---+---+-
  |   | Russell King[EMAIL PROTECTED]  --- ---
  | | | | http://www.arm.linux.org.uk/personal/aboutme.html   /  /  |
  | +-+-+ --- -+-
  /   |   THE developer of ARM Linux  |+| /|\
 /  | | | ---  |
+-+-+ -  /\\\  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Stefan Traby]

On Fri, Dec 29, 2000 at 01:06:30AM +, Albert Cranford wrote:
 Simply executing
  *p++ = htonl(fl-fl_pid);
 before 
  start = loff_t_to_s64(fl-fl_start);
 also works.

Yes, confirmed.
Since you're located in Florida I vote for this and I hope that
Linus will elect it. :)


--- linux/fs/lockd/xdr4.c.orig  Fri Dec 29 01:35:32 2000
+++ linux/fs/lockd/xdr4.c   Fri Dec 29 14:56:07 2000
@@ -167,13 +167,13 @@
 || (fl-fl_end  NLM4_OFFSET_MAX  fl-fl_end != OFFSET_MAX))
return NULL;
 
+   *p++ = htonl(fl-fl_pid);
start = loff_t_to_s64(fl-fl_start);
if (fl-fl_end == OFFSET_MAX)
len = 0;
else
len = loff_t_to_s64(fl-fl_end - fl-fl_start + 1);
 
-   *p++ = htonl(fl-fl_pid);
p = xdr_encode_hyper(p, start);
p = xdr_encode_hyper(p, len);

-- 

  ciao - 
Stefan

"export PS1="rms# "  "

Stefan TrabyLinux/ia32   fax:  +43-3133-6107-9
Mitterlasznitzstr. 13   Linux/alphaphone:  +43-3133-6107-2
8302 Nestelbach Linux/sparc   http://www.hello-penguin.com
Austriamailto:[EMAIL PROTECTED]
Europe   mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Mark Hemment]

Hi,

On Thu, 28 Dec 2000, David S. Miller wrote:
Date:  Thu, 28 Dec 2000 23:17:22 +0100
From: Andi Kleen [EMAIL PROTECTED]
 
Would you consider patches for any of these points? 
 
 To me it seems just as important to make sure struct page is
 a power of 2 in size, with the waitq debugging turned off this
 is true for both 32-bit and 64-bit hosts last time I checked.

  Checking test11 (which I'm running here), even with waitq debugging
turned off, on 32-bit (IA32) the struct page is 68bytes (since
the "age" member was re-introduced a while back).

  For my development testing, I'm running a _heavily_ hacked kernel.  One
of these hacks is to pull the wait_queue_head out of struct page; the
waitq-heads are in a separate allocated area of memory, with a waitq-head
pointer embedded in the page structure (allocated/initialised in
free_area_init_core()).  This gives a page structure of 60bytes, giving me
one free double-word to play with (which I'm using as a pointer to a
release function).

  Infact, there doesn't need to be a waitq-head allocated for each page
structure - they can share; with a performance overhead on a false
wakeup in __wait_on_page().
  Note, for those of us running on 32bit with lots of physical memory, the
available virtual address-space is of major consideration.  Reducing the
size of the page structure is more than just reducing cache misses - it
gives us more virtual to play with...

Mark

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Tim Wright]

On Fri, Dec 29, 2000 at 03:46:22PM +, Mark Hemment wrote:
   Note, for those of us running on 32bit with lots of physical memory, the
 available virtual address-space is of major consideration.  Reducing the
 size of the page structure is more than just reducing cache misses - it
 gives us more virtual to play with...
 
 Mark
 

Yes, this is a very important point if we ever want to make serious use
of large memory machines on ia32. We ran into this with DYNIX/ptx when the
P6 added 36-bit physical addressing. Conserving KVA (kernel virtual address
space), became a very high priority. Eventually, we had to add code to play
silly segment games and "magically" materialize and dematerialize a 4GB
kernel virtual address space instead of the 1GB. This only comes into play
with really large amounts of memory, and is almost certainly not worth the
agony of implementation on Linux, but we'll need to be careful elsewhere to
conserve it as much as possible.

Regards,

Tim


-- 
Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED]
IBM Linux Technology Center, Beaverton, Oregon
"Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Mark Hemment]

On Fri, 29 Dec 2000, Tim Wright wrote:
 Yes, this is a very important point if we ever want to make serious use
 of large memory machines on ia32. We ran into this with DYNIX/ptx when the
 P6 added 36-bit physical addressing. Conserving KVA (kernel virtual address
 space), became a very high priority. Eventually, we had to add code to play
 silly segment games and "magically" materialize and dematerialize a 4GB
 kernel virtual address space instead of the 1GB. This only comes into play
 with really large amounts of memory, and is almost certainly not worth the
 agony of implementation on Linux, but we'll need to be careful elsewhere to
 conserve it as much as possible.

  Indeed.  I'm compiling my kernels with 2GB virtual.  Not as I want more
NORMAL pages in the page cache (HIGH memory is fine), but as I need
NORMAL pages for kernel data/structures (memory allocated from  
slab-caches) which need to be constantly mapped in.

Mark


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Tom Rini]

On Thu, Dec 28, 2000 at 12:25:23PM -0800, Linus Torvalds wrote:

  - pre5:
- NIIBE Yutaka: SuperH update
- Geert Uytterhoeven: m68k update
- David Miller: TCP RTO calc fix, UDP multicast fix etc
- Duncan Laurie: ServerWorks PIRQ routing definition.
- mm PageDirty cleanups, added sanity checks, and don't lose the bit. 

I just noticed this (playing with some other stuff), but ext2 as a module
is currently broken:
$ make INSTALL_MOD_PATH=/tmp/foo modules_install
...
if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b /tmp/foo -r 2.4.0-test12; 
fi
depmod: *** Unresolved symbols in 
/tmp/foo/lib/modules/2.4.0-test12/kernel/fs/ext2/ext2.o
depmod: buffer_insert_inode_queue
depmod: fsync_inode_buffers

I tried the following locally and it fixes it.
---cut---
--- fs/Makefile.origFri Dec 29 10:35:50 2000
+++ fs/Makefile Fri Dec 29 10:36:06 2000
@@ -7,7 +7,7 @@
 
 O_TARGET := fs.o
 
-export-objs := filesystems.o
+export-objs := filesystems.o buffer.o
 mod-subdirs := nls
 
 obj-y :=   open.o read_write.o devices.o file_table.o buffer.o \
--- fs/buffer.c.origFri Dec 29 10:33:21 2000
+++ fs/buffer.c Fri Dec 29 10:35:46 2000
@@ -29,6 +29,7 @@
 /* async buffer flushing, 1999 Andrea Arcangeli [EMAIL PROTECTED] */
 
 #include linux/config.h
+#include linux/module.h
 #include linux/sched.h
 #include linux/fs.h
 #include linux/malloc.h
@@ -579,6 +580,8 @@
spin_unlock(lru_list_lock);
 }
 
+EXPORT_SYMBOL(buffer_insert_inode_queue);
+
 /* The caller must have the lru_list lock before calling the 
remove_inode_queue functions.  */
 static void __remove_inode_queue(struct buffer_head *bh)
@@ -900,6 +903,7 @@
return err2;
 }
 
+EXPORT_SYMBOL(fsync_inode_buffers);
 
 /*
  * osync is designed to support O_SYNC io.  It waits synchronously for
---end---

-- 
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

test13-pre5 and 8139too

[Jacobberger Mark]

I'm getting intermittent time out on my
Realtek 8139B - 8139too on eth0

Guess the problems back.

Fun..., Have to reboot my Cisco 675 

Oh well...

Frank

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] #2 VM fixes + RSS limits 2.4.0-test13-pre5 #2

[Rik van Riel]

Hi Linus, Alan,

Here is a second version of my patch ... it turned out that
fixing of the return value of try_to_swap_out() means that
swap_out_mm() doesn't unlock the mm-page_table_lock ...

The reason I didn't run into this bug yesterday was that the
RSS trimming took care of all the swapout I needed. ;)

The (small) fixes wrt. yesterday's patch are added below.

 1. trivially implement RSS ulimit support, with
p-rlim[RLIMIT_RSS].rlim_max treated as a hard limit
and .rlim_cur treated as a soft limit

1a.  don't call enforce_rss_limit() while we're holding the
 tasklist_lock ...

1b.  enforce_rss_limit() now loops a few times if the first
 scanning of the RSS didn't bring us under the soft limit

 this turned out to be needed in order to bring a task
 down to its RSS limit if the working set is bigger and
 there is no VM pressure ... whether it is good or not to
 trim to smaller than the working set I don't know, though ;))

 2. fix the return value from try_to_swap_out() to return
success whenever we make the RSS of a process smaller

2a.  fix swap_out_mm() to unlock the mm-page_table_lock
 on success as well

 3. clean up refill_inactive() ... try_to_swap_out() returns
the expected result now, so things should be balanced again
 
 4. only call deactivate_page() from generic_file_write() if we
write "beyond the end of" the page, so partially written
pages stay active and will remain in memory longer (8% more
performance for dbench, as tested by Daniel Phillips)
 
 5. (minor) s/unsigned int gfp_mask/int gfp_mask/ in vmscan.c
... we had both types used, which is rather inconsistent
 
 Please consider including this patch in the next 2.4 pre-patch,
 IMHO all of these things are fairly trivial and it seems to run
 very nicely on my test box ;)

The request for inclusion still stands ... I'll be stress-testing
my test machine all weekend while I'm away on the beach.

Other testers are requested ... how does this perform on your
machine and/or are you able to hang it?  (I guess the patch
is simple enough to not have any influence on stability)

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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



--- linux-2.4.0-test13-pre5/mm/filemap.c.orig   Thu Dec 28 19:11:39 2000
+++ linux-2.4.0-test13-pre5/mm/filemap.cThu Dec 28 19:28:06 2000
@@ -1912,7 +1912,7 @@
 
/* Make sure this doesn't exceed the process's max rss. */
error = -EIO;
-   rlim_rss = current-rlim ?  current-rlim[RLIMIT_RSS].rlim_cur :
+   rlim_rss = current-rlim ?  (current-rlim[RLIMIT_RSS].rlim_cur  PAGE_SHIFT) 
+:
LONG_MAX; /* default: see resource.h */
if ((vma-vm_mm-rss + (end - start))  rlim_rss)
return error;
@@ -2438,7 +2438,7 @@
}
 
while (count) {
-   unsigned long bytes, index, offset;
+   unsigned long bytes, index, offset, partial = 0;
char *kaddr;
 
/*
@@ -2448,8 +2448,10 @@
offset = (pos  (PAGE_CACHE_SIZE -1)); /* Within page */
index = pos  PAGE_CACHE_SHIFT;
bytes = PAGE_CACHE_SIZE - offset;
-   if (bytes  count)
+   if (bytes  count) {
bytes = count;
+   partial = 1;
+   }
 
/*
 * Bring in the user page that we will copy from _first_.
@@ -2491,9 +2493,17 @@
buf += status;
}
 unlock:
-   /* Mark it unlocked again and drop the page.. */
+   /*
+* Mark it unlocked again and release the page.
+* In order to prevent large (fast) file writes
+* from causing too much memory pressure we move
+* completely written pages to the inactive list.
+* We do, however, try to keep the pages that may
+* still be written to (ie. partially written pages).
+*/
UnlockPage(page);
-   deactivate_page(page);
+   if (!partial)
+   deactivate_page(page);
page_cache_release(page);
 
if (status  0)
--- linux-2.4.0-test13-pre5/mm/memory.c.origThu Dec 28 19:11:39 2000
+++ linux-2.4.0-test13-pre5/mm/memory.c Fri Dec 29 17:10:53 2000
@@ -1198,6 +1198,12 @@
pgd = pgd_offset(mm, address);
pmd = pmd_alloc(pgd, address);
 
+   if (mm-rss = (current-rlim[RLIMIT_RSS].rlim_max  PAGE_SHIFT)) {
+   lock_kernel();
+   enforce_rss_limit(current, GFP_HIGHUSER);
+   unlock_kernel();
+   }
+
if (pmd) {
pte_t * pte = pte_alloc(pmd, address);
if (pte)
--- linux-2.4.0-test13-pre5/mm/vmscan.c.origThu De

test13-pre5 + char-major-145??

[Frank Jacobberger]

Please help me explain why I'm getting the following
modprobe reply on boot up after kernel test13-pre5
loads:

modprobe: Can't locate module char-major-145

From /usr/src/linux/Documentation/devices.txt

10 charNon-serial mice, misc features
145 = /dev/hfmodem  Soundcard shortwave modem control {2.6}

My modules.conf:
---
alias eth0 rtl8139
alias eth1 rtl8139
alias parport_lowlevel parport_pc
alias sound-slot-0 emu10k1
alias usb-controller usb-uhci
---

What may be calling this? Any advice where to go ferreting?

Thanks,

Frank

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5 + char-major-145??

[Bernd Eckenfels]

In article [EMAIL PROTECTED] you wrote:
 What may be calling this? Any advice where to go ferreting?

Somebody may try to open the device file.

Greetings
Bernd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[David S. Miller]

   Date: Fri, 29 Dec 2000 15:46:22 + (GMT)
   From: Mark Hemment [EMAIL PROTECTED]

 For my development testing, I'm running a _heavily_ hacked
   kernel.  One of these hacks is to pull the wait_queue_head out of
   struct page; the waitq-heads are in a separate allocated area of
   memory, with a waitq-head pointer embedded in the page structure
   (allocated/initialised in free_area_init_core()).  This gives a
   page structure of 60bytes, giving me one free double-word to play
   with (which I'm using as a pointer to a release function).

Not something like those damn Solaris turnstiles, no please

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Fri, 29 Dec 2000, David S. Miller wrote:
 
  For my development testing, I'm running a _heavily_ hacked
kernel.  One of these hacks is to pull the wait_queue_head out of
struct page; the waitq-heads are in a separate allocated area of
memory, with a waitq-head pointer embedded in the page structure
(allocated/initialised in free_area_init_core()).  This gives a
page structure of 60bytes, giving me one free double-word to play
with (which I'm using as a pointer to a release function).
 
 Not something like those damn Solaris turnstiles, no please

If you want to have a release function, please just use "page-mapping",
which gives you much more, including memory pressure indicators etc. Now
_that_ can be useful for doing things like slab caches.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5 + char-major-145??

[Keith Owens]

On Fri, 29 Dec 2000 14:07:57 -0700, 
Frank Jacobberger [EMAIL PROTECTED] wrote:
modprobe: Can't locate module char-major-145

From /usr/src/linux/Documentation/devices.txt

10 charNon-serial mice, misc features
145 = /dev/hfmodem  Soundcard shortwave modem control {2.6}

That is major 10, minor 145.  Search /145 *char/ to find char-major-145.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] i810 audio fixes for 2.4.0-test13-pre5

[Jim Studt]

This patch addresses three problems in the i810-audio driver for
2.4.0-test13-pre5.  I will be happy to split it if someone doesn't like
part of it.  (I see pre6 just popped out, there are no changes to this
driver in pre6.)

1) "DMA overrun on send" - this contains a patch from Tjeerd Mulder that
   prevents almost all of this.  I still get an occasional one during
   heavy video activity, the driver was unusable before.  (This is a smaller 
   patch than the previous flamed patch, it does no format conversion.)

2) Enable codec rate adaption - the current rate setting functions attempt 
   to get the codecs to rate adapt, but neglect to turn on the bit in the
   "Extended Audio Status and Control Register" that allows the codec to 
   actually adapt.  (Audio Codec '97, Rev 2.2, Intel, section 5.8.2)
   This allows audio of other than 48kHz if the codec supports it.

3) Add a module parameter to supress powercycling the DACs on rate change -
   This causes a big pop on the outputs at least for the CS4299 codec in
   the emachines etower 700, probably others.  I honestly can't find a 
   reason to power cycle the DACs.  There's nothing in the AC97 spec 
   that suggests it should be done.  The code is common to OSS and ALSA.
   I left the old behavior as the default.  Maybe later the default should
   change if it turns out that everyone wants to force the parameter to 
   zero.

After this is applied I will followup with another patch that 
adds /proc/driver/i810-audio/... support like the via82cxxx driver.
I don't know is user's need it, but it sure helps debugging and 
figuring out what sort of hardware is really in the computer.




--- clean-linux/drivers/sound/i810_audio.c  Wed Nov  8 19:09:50 2000
+++ linux/drivers/sound/i810_audio.cFri Dec 29 18:10:19 2000
@@ -102,6 +102,7 @@
 
 static int ftsodell=0;
 static unsigned int clocking=48000;
+static int cycle_power=1;
 
 
 #define ADC_RUNNING1
@@ -382,7 +383,7 @@
 static unsigned int i810_set_dac_rate(struct i810_state * state, unsigned int rate)
 {  
struct dmabuf *dmabuf = state-dmabuf;
-   u32 dacp;
+   u32 dacp=0;
struct ac97_codec *codec=state-card-ac97_codec[0];

if(!(state-card-ac97_features0x0001))
@@ -410,14 +411,23 @@
 
if(rate != i810_ac97_get(codec, AC97_PCM_FRONT_DAC_RATE))
{
+   u16 extended_status = i810_ac97_get(codec, AC97_EXTENDED_STATUS);
+
+   /* enable variable rate audio */
+   if ( !(extended_status1)) {
+   i810_ac97_set(codec, AC97_EXTENDED_STATUS, extended_status | 
+1);
+   }
+
/* Power down the DAC */
-   dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
-   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0200);
+   if ( cycle_power) {
+   dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
+   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0200);
+   }
/* Load the rate and read the effective rate */
i810_ac97_set(codec, AC97_PCM_FRONT_DAC_RATE, rate);
rate=i810_ac97_get(codec, AC97_PCM_FRONT_DAC_RATE);
/* Power it back up */
-   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
+   if ( cycle_power) i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
}
rate=(rate * 48000) / clocking;
dmabuf-rate = rate;
@@ -432,7 +442,7 @@
 static unsigned int i810_set_adc_rate(struct i810_state * state, unsigned int rate)
 {
struct dmabuf *dmabuf = state-dmabuf;
-   u32 dacp;
+   u32 dacp=0;
struct ac97_codec *codec=state-card-ac97_codec[0];

if(!(state-card-ac97_features0x0001))
@@ -460,14 +470,22 @@
 
if(rate != i810_ac97_get(codec, AC97_PCM_LR_DAC_RATE))
{
+   u16 extended_status = i810_ac97_get(codec, AC97_EXTENDED_STATUS);
+   /* enable variable rate audio */
+   if ( !(extended_status1)) {
+   i810_ac97_set(codec, AC97_EXTENDED_STATUS, extended_status | 
+1);
+   }
+
/* Power down the ADC */
-   dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
-   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0100);
+   if ( cycle_power) {
+   dacp=i810_ac97_get(codec, AC97_POWER_CONTROL);
+   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp|0x0100);
+   }
/* Load the rate and read the effective rate */
i810_ac97_set(codec, AC97_PCM_LR_DAC_RATE, rate);
rate=i810_ac97_get(codec, AC97_PCM_LR_DAC_RATE);
/* Power it back up */
-   i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
+   if ( cycle_power) i810_ac97_set(codec, AC97_POWER_CONTROL, dacp);
}
rate = (rate

VIA IDE controller strangeness (2.4.0-test12/test13-pre5)

[Evan Thompson]

---(CC answer please)---

I'm having a strange problem with my IDE controller.  I believe (and that's what 
Windows and the m/b manufaturer -- PC Chips -- say) that I have a VIA PCI BusMaster 
IDE controller, and I've had some strange history with it.  I've asked many people 
before on various help services, and I was able to fix my problem with the 2.2 series, 
but now my fix does not work.

THE PROBLEM:


Ever since the 2.2 kernel series (I remeber this working properly in 2.0.36, without 
the conflicts), I would get hdc: lost interrupt during boot up, and my system would 
take bloody ages to boot up and load a CD.  I tracked it down to a strange IRQ 
conflict in which Linux would try to assign both the primary and secondary IDE 
channels IRQ 14, causing IRQ conflicts galore.  I was able to fix this by giving the 
kernel

ide1=0x170,0x376,15

at boot time.  This has worked for 2.2.12-.17 and Alan's 2.2.18pre21 (I haven't 
compiled the official 2.2.18 yet, but I'm sure it will work).

I wanted to try the new 2.4.0-test series, and the first I tried was -test11, and from 
what I recall (other things weren't working properly then), this fix still worked, but 
now, with -test12, I am now getting the following error repeated for a very long time 
(then I reboot) with the same parameters:

ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
hdb: lost interrupt

Also, I get "spurious 8259A interrupt: IRQ 7" if I leave it for a while.  I tried 
-test13-pre5 on somebody on #KernelNewbies' suggestion, and I get the same error.  
Scrolling up, I see that the kernel messages show that ide0 is on IRQ 14 and ide1 is 
on 15.  I noticed that hda is using DMA, and hdb is using UDMA33, but I don't believe 
that that is the problem.

THE QUESTION:
-

How do I fix this, or is it a (un)known problem in the newer development versions?  If 
you have the answer, could you please CC me as well for I don't subscribe to this 
mailing list (sorry!).  Thanks a bunch.
-- 
| Evan A. Thompson | He's more fun than trying to skinny  | 
| [EMAIL PROTECTED]   | dip in the beach in winter...|
| http://evaner.penguinpowered.com |...in Winnipeg.   |
| ICQ: 2233067 / AIM + MSN: Evaner517  |  (GnuPG key avaiable upon request.)  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] i810 audio fixes for 2.4.0-test13-pre5

[Alan Cox]

 This patch addresses three problems in the i810-audio driver for
 2.4.0-test13-pre5.  I will be happy to split it if someone doesn't like
 part of it.  (I see pre6 just popped out, there are no changes to this
 driver in pre6.)

 1) "DMA overrun on send" - this contains a patch from Tjeerd Mulder that
prevents almost all of this.  I still get an occasional one during
heavy video activity, the driver was unusable before.  (This is a smaller 
patch than the previous flamed patch, it does no format conversion.)

Yeah I have Tjeerd's patches and no quibbles with them

 3) Add a module parameter to supress powercycling the DACs on rate change -
This causes a big pop on the outputs at least for the CS4299 codec in
the emachines etower 700, probably others.  I honestly can't find a 
reason to power cycle the DACs.  There's nothing in the AC97 spec 
that suggests it should be done.  The code is common to OSS and ALSA.
I left the old behavior as the default.  Maybe later the default should
change if it turns out that everyone wants to force the parameter to 
zero.

What I would love someone to do (hint ;)) is to move the 

set_dac_speed
set_adc_speed
powerup_amp
powerdown_amp

type stuff into the ac97_codec - actually have a codec_ops in the AC97 
for each type.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Dieter Nützel]

Am Freitag, 29. Dezember 2000 14:38 schrieben Sie:
 On Fri, 29 Dec 2000, Dieter Nützel wrote:
  your patch didn't apply clean.
  Have you another version?

 It should apply just fine. What error messages did
 patch give ?

Applied #2 against my running 2.4.0-test13-pre5 + ReiserFS 3.6.23 tree and
a clean test13-pre5 (test12 + test13-pre5). Same for both of them:

SunWave1patch -p0 -E -N patches/2.4.0-test13-pre5-VM-fix
patching file `linux-2.4.0-test13-pre5/mm/filemap.c'
Hunk #1 FAILED at 1912.
Hunk #2 FAILED at 2438.
Hunk #3 FAILED at 2448.
Hunk #4 FAILED at 2493.
4 out of 4 hunks FAILED -- saving rejects to 
linux-2.4.0-test13-pre5/mm/filemap.c.rej
patching file `linux-2.4.0-test13-pre5/mm/memory.c'
Hunk #1 FAILED at 1198.
1 out of 1 hunk FAILED -- saving rejects to 
linux-2.4.0-test13-pre5/mm/memory.c.rej
patching file `linux-2.4.0-test13-pre5/mm/vmscan.c'
Hunk #1 FAILED at 49.
Hunk #2 FAILED at 59.
Hunk #3 FAILED at 92.
Hunk #4 FAILED at 108.
Hunk #5 FAILED at 159.
Hunk #6 FAILED at 200.
Hunk #7 FAILED at 271.
Hunk #8 FAILED at 290.
Hunk #9 FAILED at 310.
Hunk #10 succeeded at 390 with fuzz 2.
Hunk #11 FAILED at 430.
Hunk #12 FAILED at 575.
Hunk #13 FAILED at 586.
Hunk #14 FAILED at 618.
Hunk #15 FAILED at 932.
Hunk #16 FAILED at 944.
Hunk #17 FAILED at 953.
Hunk #18 FAILED at 972.
Hunk #19 succeeded at 1007 with fuzz 2.
Hunk #20 succeeded at 1182 with fuzz 2.
17 out of 20 hunks FAILED -- saving rejects to 
linux-2.4.0-test13-pre5/mm/vmscan.c.rej
patching file `linux-2.4.0-test13-pre5/include/linux/mm.h'
Hunk #1 succeeded at 460 with fuzz 2.
patching file `linux-2.4.0-test13-pre5/include/linux/swap.h'

filemap.c : offset of 3 lines needed
memory.c : dito
vmscan.c : dito

Now, I hacked it by 'hand' and got it running.
I did dbench and saw nearly same results then Daniel Phillips
But my disk is to small. Some writes failed...:-(

Test machine: 256 MB, Athlon 550 SlotA, SCSI, ReiserFS 3.6.23, Blocksize=4K
Test: dbench 48

Throughput: 10.89 MB/sec
Elapsed Time:   9 min 47 secs

"Guten Rutsch in's neue Jahr!" :-)

-Dieter
-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
Department of Computer Science
Cognitive Systems Group
Vogt-Kölln-Straße 30
D-22527 Hamburg, Germany

email: [EMAIL PROTECTED]
@home: [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

(REPOST-sorry) PCI VIA IDE Strangeness w/2.4.0-test12/test13-pre5

[Evan Thompson]

REPOST: People have asked me to repost this message because their e-mail clients
don't wrap lines.  I'd like to know which ones don't, but this isn't the list
for that kind of question, unless it is, which then means I'm posting to the
wrong list to start with and then I wouldn't have to repost.  Anyways...

---(CC answer please)---

I'm having a strange problem with my IDE controller.  I believe (and that's
what Windows and the m/b manufaturer -- PC Chips -- say) that I have a VIA PCI
BusMaster IDE controller, and I've had some strange history with it.  I've
asked many people before on various help services, and I was able to fix my
problem with the 2.2 series, but now my fix does not work.

THE PROBLEM:


Ever since the 2.2 kernel series (I remeber this working properly in 2.0.36,
without the conflicts), I would get hdc: lost interrupt during boot up, and my
system would take bloody ages to boot up and load a CD.  I tracked it down to a
strange IRQ conflict in which Linux would try to assign both the primary and
secondary IDE channels IRQ 14, causing IRQ conflicts galore.  I was able to fix
this by giving the kernel

ide1=0x170,0x376,15

at boot time.  This has worked for 2.2.12-.17 and Alan's 2.2.18pre21 (I haven't
compiled the official 2.2.18 yet, but I'm sure it will work).

I wanted to try the new 2.4.0-test series, and the first I tried was -test11,
and from what I recall (other things weren't working properly then), this fix
still worked, but now, with -test12, I am now getting the following error
repeated for a very long time (then I reboot) with the same parameters:

ide_dmaproc: chipset supported ide_dma_lostirq func only: 13
hdb: lost interrupt

Also, I get "spurious 8259A interrupt: IRQ 7" if I leave it for a while.  I
tried -test13-pre5 on somebody on #KernelNewbies' suggestion, and I get the
same error.  Scrolling up, I see that the kernel messages show that ide0 is on
IRQ 14 and ide1 is on 15.  I noticed that hda is using DMA, and hdb is using
UDMA33, but I don't believe that that is the problem.

THE QUESTION:
-

How do I fix this, or is it a (un)known problem in the newer development
versions?  If you have the answer, could you please CC me as well for I don't
subscribe to this mailing list (sorry!).  Thanks a bunch.
-- 
| Evan A. Thompson | He's more fun than trying to skinny  | 
| [EMAIL PROTECTED]   | dip in the beach in winter...|
| http://evaner.penguinpowered.com |...in Winnipeg.   |
| ICQ: 2233067 / AIM + MSN: Evaner517  |  (GnuPG key avaiable upon request.)  |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

PATCH: test13-pre5/drivers/sound/via82cxxx_audio.c did not compile

[Adam J. Richter]

linux-2.4.0-test13-pre5 eliminated vm_operations_struct-swapout,
but this change was not reflected in drivers/sound/via82cxxx_audio.c,
causing that file to fail to compile.  I have attached what I believe
is the correct fix below.

via82cxxx_audio.c has Jeff Garzik's name on it, but I understand
that he is taking a break for a few weeks to recover from typing strain.
(Hope you recover soon, Jeff.)  Consequently, I am not sure whom I should
ask to "bless" this change.  So, I'll just send this to linux-kernel
and Linus and will leave it to linux-kernel readers to sound the alarm
if I botched the patch.

-- 
Adam J. Richter __ __   4880 Stevens Creek Blvd, Suite 104
[EMAIL PROTECTED] \ /  San Jose, California 95129-1034
+1 408 261-6630 | g g d r a s i l   United States of America
fax +1 408 261-6631  "Free Software For The Rest Of Us."


--- linux-2.4.0-test13-pre5/drivers/sound/via82cxxx_audio.c Mon Oct 30 12:24:22 
2000
+++ linux/drivers/sound/via82cxxx_audio.c   Fri Dec 29 16:53:22 2000
@@ -1727,20 +1727,8 @@
 }
 
 
-#ifndef VM_RESERVE
-static int via_mm_swapout (struct page *page, struct file *filp)
-{
-   return 0;
-}
-#endif /* VM_RESERVE */
-
-
 struct vm_operations_struct via_mm_ops = {
nopage: via_mm_nopage,
-
-#ifndef VM_RESERVE
-   swapout:via_mm_swapout,
-#endif
 };
 
 

Re: PATCH: test13-pre5/drivers/sound/via82cxxx_audio.c did notcompile

[Linus Torvalds]

On Fri, 29 Dec 2000, Adam J. Richter wrote:

   linux-2.4.0-test13-pre5 eliminated vm_operations_struct-swapout,
 but this change was not reflected in drivers/sound/via82cxxx_audio.c,
 causing that file to fail to compile.  I have attached what I believe
 is the correct fix below.

Actually, the right fix is to change all VM_RESERVE to VM_RESERVED (ie add
a "D" at the end), at which point it should compile and work fine..

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Albert Cranford]

Simply executing
 *p++ = htonl(fl->fl_pid);
before 
 start = loff_t_to_s64(fl->fl_start);
also works.
Later,
Albert

Linus Torvalds wrote:
> 
> On Fri, 29 Dec 2000, Stefan Traby wrote:
> > On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote:
> >
> > > Too bad. Maybe somebody should tell gcc maintainers about programmers that
> > > know more than the compiler again.
> >
> > I know that {p,}gcc-2.95.2{,.1} are not officially supported.
> 
> Hmm, I use gcc-2.95.2 myself on some machines, and while I'm not 100%
> comfortable with it, it does count as "supported" even if it has known
> problems with "long long". pgcc isn't.
> 
> > Did you know that it's impossible to compile nfsv4 because of
> > register allocation problems with long long since (long long) month ?
> 
> lockd v4 (for NFS v3), I assume.
> 
> No, I wasn't aware of this particular bug.
> 
> > The following does not hurt, it's just a fix for a broken
> > compiler:
> 
> Ugh, that's ugly.
> 
> Can you test if it is sufficient to just simplify the math a bit, instead
> of uglyfing that function more? The nlm4_encode_lock() function already
> tests for NLM4_OFFSET_MAX explicitly for both start and end, so it should
> be ok to just re-code the function to not do the extra "loff_t_to_s64()"
> stuff, and simplify it enough that the compile rwill be happy to compile
> the simpler function. Something along the lines of
> 
> if (.. NLM4_OFFSET_MAX tests ..)
> ..
> 
> *p++ = htonl(fl->fl_pid);
> 
> start = fl->fl_start;
> len = fl->fl_end - start;
> if (fl->fl_end == OFFSET_MAX)
> len = 0;
> 
> p = xdr_encode_hyper(p, start);
> p = xdr_encode_hyper(p, len);
> 
> return p;
> 
> Where it tries to minimize the liveness of the 64-bit values, and tries to
> avoid extra complications.
> 
> Linus
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> Please read the FAQ at http://www.tux.org/lkml/

-- 
Albert Cranford Deerfield Beach FL USA
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Fri, 29 Dec 2000, Stefan Traby wrote:
> On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote:
> 
> > Too bad. Maybe somebody should tell gcc maintainers about programmers that
> > know more than the compiler again.
> 
> I know that {p,}gcc-2.95.2{,.1} are not officially supported.

Hmm, I use gcc-2.95.2 myself on some machines, and while I'm not 100%
comfortable with it, it does count as "supported" even if it has known
problems with "long long". pgcc isn't.

> Did you know that it's impossible to compile nfsv4 because of
> register allocation problems with long long since (long long) month ?

lockd v4 (for NFS v3), I assume. 

No, I wasn't aware of this particular bug. 

> The following does not hurt, it's just a fix for a broken
> compiler:

Ugh, that's ugly.

Can you test if it is sufficient to just simplify the math a bit, instead
of uglyfing that function more? The nlm4_encode_lock() function already
tests for NLM4_OFFSET_MAX explicitly for both start and end, so it should
be ok to just re-code the function to not do the extra "loff_t_to_s64()"
stuff, and simplify it enough that the compile rwill be happy to compile
the simpler function. Something along the lines of

if (.. NLM4_OFFSET_MAX tests ..)
..

*p++ = htonl(fl->fl_pid);

start = fl->fl_start;
len = fl->fl_end - start;
if (fl->fl_end == OFFSET_MAX)
len = 0;

p = xdr_encode_hyper(p, start);
p = xdr_encode_hyper(p, len);

return p;

Where it tries to minimize the liveness of the 64-bit values, and tries to
avoid extra complications.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Thu, 28 Dec 2000, Marcelo Tosatti wrote:
> 
> We also want to move the page to the per-address-space clean list in
> ClearPageDirty I suppose.

I would actually advice against this.

 - it's ok to have too many pages on the dirty list (think o fthe dirty
   list as a "these pages _can_ be dirty")

 - whenever we do a ClearPageDirty() we're likely to remove the page from
   the lists altogether, so it's not worth it doing extra work.

The exception, of course, is the actual "filemap_fdatasync()" function,
but that one would probably look something like

spin_lock(_cache_lock);
while (!list_empty(>dirty_pages)) {
struct page *page = list_entry(mapping->dirty_pages.next, struct page, 
list);

list_del(>list);
list_add(>list, >clean_pages);

if (!PageDirty(page))
continue;
page_get(page);
spin_unlock(_cache_lock);

lock_page(page);
if (PageDirty(page)) {
ClearPageDirty(page);
page->mapping->writepage(page);
}
UnlockPage(page);
page_cache_put(page);
spin_lock(_cache_lock);
}
spin_unlock(_cache_lock);

and again note how we can move it to the clean list early and we don't
have to keep the PageDirty bit 100% in sync with which list is it on. If
somebody marks it dirty later on (and the dirty bit is still set), that
somebody won't move it back to the dirty list (because it noticved that
the dirty bit is already set), but that's ok: as long as we do the
"ClearPageDirty(page);" call before startign the actual writeout(), we're
fine.

So the "mapping->dirty_pages" list is maybe not so much a _dirty_ list, as
a "scheduled for writeout" list. Marking the page clean doesn't remove it
from that list - it can happily stay on the list and then when the
writeout is started we'd just skip it.

Ok?

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Stefan Traby]

On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote:

> Too bad. Maybe somebody should tell gcc maintainers about programmers that
> know more than the compiler again.

I know that {p,}gcc-2.95.2{,.1} are not officially supported.

Did you know that it's impossible to compile nfsv4 because of
register allocation problems with long long since (long long) month ?

The following does not hurt, it's just a fix for a broken
compiler:

--- linux/fs/lockd/xdr4.c.orig  Fri Dec 29 01:35:32 2000
+++ linux/fs/lockd/xdr4.c   Fri Dec 29 01:36:36 2000
@@ -156,7 +156,7 @@
 nlm4_encode_lock(u32 *p, struct nlm_lock *lock)
 {
struct file_lock*fl = >fl;
-   __s64   start, len;
+   volatile __s64  start, len;

if (!(p = xdr_encode_string(p, lock->caller))
 || !(p = nlm4_encode_fh(p, >fh))


Here is an example without this patch (pgcc-2.95.2.1 this time which
is bug-compatible to gcc-2.95.2.1).

gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 
-fomit-frame-pointer -fno-strict-aliasing -pipe -mpreferred-stack-boundary=2 
-march=i686 -DMODULE   -c -o xdr4.o xdr4.c
xdr4.c: In function `nlm4_encode_lock':
xdr4.c:181: internal error--insn does not satisfy its constraints:
(insn/i 313 585 315 (set (reg:SI 1 %edx)
(subreg:SI (lshiftrt:DI (reg:DI 0 %eax)
(const_int 32 [0x20])) 0)) 323 {lshrdi3_const_int_subreg} (nil)
(nil))
gcc: Internal compiler error: program cpp got fatal signal 13
make[2]: *** [xdr4.o] Error 1
make[2]: Leaving directory `/.localvol000/usr/src/linux-2.4.0-test13pre5/fs/lockd'
make[1]: *** [_modsubdir_lockd] Error 2
make[1]: Leaving directory `/.localvol000/usr/src/linux-2.4.0-test13pre5/fs'
make: *** [_mod_fs] Error 2

The question is: Is it worth to apply ?

-- 

  ciao - 
Stefan

"export PS1="rms# "  "

Stefan TrabyLinux/ia32   fax:  +43-3133-6107-9
Mitterlasznitzstr. 13   Linux/alphaphone:  +43-3133-6107-2
8302 Nestelbach Linux/sparc   http://www.hello-penguin.com
Austriamailto:[EMAIL PROTECTED]
Europe   mailto:[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Marcelo Tosatti]

On Thu, 28 Dec 2000, Linus Torvalds wrote:

>  - make "SetPageDirty()" do something like
> 
>   if (!test_and_set(PG_dirty, >flags)) {
>   spin_lock(_cache_lock);
>   list_del(page->list);
>   list_add(page->list, page->mapping->dirty_pages);
>   spin_unlock(_cache_lock);
>   }
> 
>This will require making sure that every place that does a
>SetPageDirty() will be ok with this (ie double-check that they all have
>a mapping: right now the free_pte() code in mm/memory.c doesn't care,
>because it knew that it coul dmark even anonymous pages dirty and
>they'd just get ignored.
>  - make a filemap_fdatasync() that walks the dirty pages and does a
>writepage() on them all and moves them to the clean list.

We also want to move the page to the per-address-space clean list in
ClearPageDirty I suppose.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Thu, Dec 28, 2000 at 03:37:51PM -0800, Linus Torvalds wrote:
> 
> 
> On Fri, 29 Dec 2000, Andi Kleen wrote:
> > 
> > Hopefully all the "goto out" micro optimizations can be taken out then too,
> 
> "goto out" often generates much more readable code, so the optimization is
> secondary.

I was more thinking of cases like the scheduler's gotos, which has gotten
rather spagetti recently. Admittedly classic goto out is often more readable
than many nested if()s with error handling.

> 
> > I recently found out that gcc 2.97's block moving pass has the tendency
> > to move the outlined blocks inline again ;) 
> 
> Too bad. Maybe somebody should tell gcc maintainers about programmers that
> know more than the compiler again.

In x86-64 which relies on 2.97 I'm using __builtin_expect, defined to 
likely() and unlikely(), which seems to generate good code.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Thu, Dec 28, 2000 at 03:14:56PM -0800, David S. Miller wrote:
>Date: Fri, 29 Dec 2000 00:17:21 +0100
>From: Andi Kleen <[EMAIL PROTECTED]>
> 
>On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote:
>> To make things like "page - mem_map" et al. use shifts instead of
>> expensive multiplies...
> 
>I thought that is what ->index is for ? 
> 
> It is for the page cache identity Andi... you know, page_hash(mapping, index)...

Oops, I confused it with the 2.0 page->map_nr, which did exactly that.

I should have known better.  Thanks for correcting this brainfart.

> And the add/sub/shift expansion of a multiply/divide by constant even
> in its' most optimal form is often not trivial, it is something on the
> order of 7 instructions with waitq debugging enabled last time I
> checked.

Wonder if it looks better with wq debugging turned off or a compressed
->zone.


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Fri, 29 Dec 2000, Andi Kleen wrote:
> 
> Hopefully all the "goto out" micro optimizations can be taken out then too,

"goto out" often generates much more readable code, so the optimization is
secondary.

> I recently found out that gcc 2.97's block moving pass has the tendency
> to move the outlined blocks inline again ;) 

Too bad. Maybe somebody should tell gcc maintainers about programmers that
know more than the compiler again.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Fri, 29 Dec 2000, Andi Kleen wrote:

> On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote:
> >Date: Thu, 28 Dec 2000 23:58:36 +0100
> >From: Andi Kleen <[EMAIL PROTECTED]>
> > 
> >Why exactly a power of two ? To get rid of ->index ? 
> > 
> > To make things like "page - mem_map" et al. use shifts instead of
> > expensive multiplies...
> 
> I thought that is what ->index is for ? 

No. "index" only gives the virtual index.

"page - mem_map" is how you get the _physical_ index in the zone in
question, which is common for physical tranlations (ie "pte_page()",
"page_to_virt()" or "page_to_phys()")

> Also gcc seems to be already quite clever at dividing through small
> integers, e.g. using mul and shift and sub, so it may not be even worth to reach
> for a real power-of-two. 

Look at the code - it's a big multiply to do a divide by 68 or similar.
Quite expensive.

Doing "page->address - TASK_SIZE" on x86 for the non-highmem case would
probably be faster.

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[David S. Miller]

   Date: Fri, 29 Dec 2000 00:17:21 +0100
   From: Andi Kleen <[EMAIL PROTECTED]>

   On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote:
   > To make things like "page - mem_map" et al. use shifts instead of
   > expensive multiplies...

   I thought that is what ->index is for ? 

It is for the page cache identity Andi... you know, page_hash(mapping, index)...

And the add/sub/shift expansion of a multiply/divide by constant even
in its' most optimal form is often not trivial, it is something on the
order of 7 instructions with waitq debugging enabled last time I
checked.

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Rik van Riel]

On Fri, 29 Dec 2000, Andi Kleen wrote:
> On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote:
> >Date: Thu, 28 Dec 2000 23:58:36 +0100
> >From: Andi Kleen <[EMAIL PROTECTED]>
> > 
> >Why exactly a power of two ? To get rid of ->index ? 
> > 
> > To make things like "page - mem_map" et al. use shifts instead of
> > expensive multiplies...
> 
> I thought that is what ->index is for ? 

Nope, ->index is there to identify which offset the page
has in ->mapping, read mm/filemap.c::__find_page_nolock()
for more info.

> Also gcc seems to be already quite clever at dividing through
> small integers, e.g. using mul and shift and sub, so it may not
> be even worth to reach for a real power-of-two.
> 
> I suspect doing the arithmetics is at least faster than eating the 
> cache misses because of ->index. 

I'm pretty confident that arithmetic is faster than cache
misses ... but an unlucky size of the page struct will cause
extra cache misses due to misalignment.

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Thu, Dec 28, 2000 at 03:15:01PM -0800, Linus Torvalds wrote:
> > (first number for 32bit, second for 64bit) 
> > 
> > - Do not compile virtual in when the kernel does not support highmem
> > (saves 4/8 bytes) 
> 
> Even on UP, "virtual" often helps. The conversion from "struct page" to
> the linear address is quite common, and if "struct page" isn't a
> power-of-two it gets slow.

Are you sure? Last time I checked gcc did a very good job at optimizing
small divisions with small integers, without using div. It just has to 
be a good integer with not too many set bits.

> is 100% accurate, we _do_ care that the fields close-by don't get strange
> effects from updating "age". We used to have exactly this problem on alpha
> back in the 2.1.x timeframe.

When it is shared with a constant field (like zone index) it shouldn't
matter, no ? At worst you can see outdated data, and when the outdated
data is constant all is fine.

> > - flags can be __u32 on 64bit hosts, sharing 64bit with something that
> > is tolerant to async updates (e.g. the zone table index or the index) 
> > - index could be probably u32 instead of unsigned long, saving 4 bytes
> > on i386
> 
> It already _is_ 32-bit on x86. 

Oops. It was a typo. I meant to write "saving 4 bytes on 64bit"

> Anyway, I don't want to increase "struct page" in size, but I also don't
> think it's worth micro-optimizing some of these things if the code gets
> harder to maintain (like the partial-word stuff would be).

Ok pity :-/

Hopefully all the "goto out" micro optimizations can be taken out then too,
I recently found out that gcc 2.97's block moving pass has the tendency
to move the outlined blocks inline again ;) 



-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Thu, Dec 28, 2000 at 02:54:52PM -0800, David S. Miller wrote:
>Date: Thu, 28 Dec 2000 23:58:36 +0100
>From: Andi Kleen <[EMAIL PROTECTED]>
> 
>Why exactly a power of two ? To get rid of ->index ? 
> 
> To make things like "page - mem_map" et al. use shifts instead of
> expensive multiplies...

I thought that is what ->index is for ? 

Also gcc seems to be already quite clever at dividing through small
integers, e.g. using mul and shift and sub, so it may not be even worth to reach
for a real power-of-two. 

I suspect doing the arithmetics is at least faster than eating the 
cache misses because of ->index. 

-Andikkk


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Linus Torvalds]

On Thu, 28 Dec 2000, Andi Kleen wrote:
> 
> BTW..
> 
> The current 2.4 struct page could be already shortened a lot, saving a lot
> of cache.

Not that much, but some.

> (first number for 32bit, second for 64bit) 
> 
> - Do not compile virtual in when the kernel does not support highmem
> (saves 4/8 bytes) 

Even on UP, "virtual" often helps. The conversion from "struct page" to
the linear address is quite common, and if "struct page" isn't a
power-of-two it gets slow.

> - Instead of having a zone pointer mask use a 8 or 16 byte index into a 
> zone table. On a modern CPU it is much cheaper to do the and/shifts than
> to do even a single cache miss during page aging. On a lot of systems 
> that zone index could be hardcoded to 0 anyways, giving better code.
> - Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which
> has the same swapping algorithm even only uses 8bit) 

This would be good, but can be hard.

FreeBSD doesn't try to be portable any more, but Linux does, and there are
architectures where 8- and 16-bit accesses aren't atomic but have to be
done with read-modify-write cycles.

And even for fields like "age", where we don't care whether the age itself
is 100% accurate, we _do_ care that the fields close-by don't get strange
effects from updating "age". We used to have exactly this problem on alpha
back in the 2.1.x timeframe.

This is why a lot of fields are 32-bit, even though we wouldn't need more
than 8 or 16 bits of them.

> - Remove the waitqueue debugging (obvious @)

Not obvious enough. There are magic things that could be done, like hiding
the wait-queue lock bit in the waitqueue lists themselves etc. That could
be done with some per-architecture magic etc.

> - flags can be __u32 on 64bit hosts, sharing 64bit with something that
> is tolerant to async updates (e.g. the zone table index or the index) 
> - index could be probably u32 instead of unsigned long, saving 4 bytes
> on i386

It already _is_ 32-bit on x86. 

Only the LSF patches made it 64-bit. That never made it into the standard
kernel.

Sure, we could make it "u32" and thus force it to be 32-bit even on 64-bit
architectures, but some day somebody will want to have more than 46 bits
of file mappings, and which 46 bits is _huge_ on a 32-bit machine, on a
64-bit one in 5 years it will not be entirely unreasonable. 

Anyway, I don't want to increase "struct page" in size, but I also don't
think it's worth micro-optimizing some of these things if the code gets
harder to maintain (like the partial-word stuff would be).

The biggest win by far would come from increasing the page-size, something
we can do even in software. Having a "kernel page size" of 8kB even on x86
would basically cut the overhead in half. As that would also improve some
other things (like having better throughput due to bigger contiguous
chunks), that's something I'd like to see some day.

(And user space wouldn't ever have to know - we could map in "half pages"
aka "hardware pages" without mappign the whole page).

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[David S. Miller]

   Date: Thu, 28 Dec 2000 23:58:36 +0100
   From: Andi Kleen <[EMAIL PROTECTED]>

   Why exactly a power of two ? To get rid of ->index ? 

To make things like "page - mem_map" et al. use shifts instead of
expensive multiplies...

Later,
David S. Miller
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Rik van Riel]

On Thu, 28 Dec 2000, Andi Kleen wrote:
> On Thu, Dec 28, 2000 at 02:33:07PM -0800, David S. Miller wrote:
> >Date:Thu, 28 Dec 2000 23:17:22 +0100
> >From: Andi Kleen <[EMAIL PROTECTED]>
> > 
> >Would you consider patches for any of these points? 
> > 
> > To me it seems just as important to make sure struct page is
> > a power of 2 in size, with the waitq debugging turned off this
> > is true for both 32-bit and 64-bit hosts last time I checked.
> 
> Why exactly a power of two ? To get rid of ->index ? 

Most likely to minimise the number of cache misses needed
to access a complete page_struct.

Then again, I guess 48 bytes would _also_ guarantee that
we never need more than 2 cache misses to access every
part of the page_struct.

And the memory wasted in the page_struct may well be a
bigger factor than the cache misses on lots of systems...

(time for another CONFIG option? ;))

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Andi Kleen]

On Thu, Dec 28, 2000 at 02:33:07PM -0800, David S. Miller wrote:
>Date:  Thu, 28 Dec 2000 23:17:22 +0100
>From: Andi Kleen <[EMAIL PROTECTED]>
> 
>Would you consider patches for any of these points? 
> 
> To me it seems just as important to make sure struct page is
> a power of 2 in size, with the waitq debugging turned off this
> is true for both 32-bit and 64-bit hosts last time I checked.

Why exactly a power of two ? To get rid of ->index ? 


-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[David S. Miller]

   Date:Thu, 28 Dec 2000 23:17:22 +0100
   From: Andi Kleen <[EMAIL PROTECTED]>

   Would you consider patches for any of these points? 

To me it seems just as important to make sure struct page is
a power of 2 in size, with the waitq debugging turned off this
is true for both 32-bit and 64-bit hosts last time I checked.

Later,
David S. Miller
[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[PATCH] VM fixes + RSS limits 2.4.0-test13-pre5

[Rik van Riel]

Hi Linus,

I know this is probably not the birthday present you've been
hoping for, but here is a patch agains 2.4.0-test13-pre5 which
does the following - trivial - things:

1. trivially implement RSS ulimit support, with
   p->rlim[RLIMIT_RSS].rlim_max treated as a hard limit
   and .rlim_cur treated as a soft limit

2. fix the return value from try_to_swap_out() to return
   success whenever we make the RSS of a process smaller

3. clean up refill_inactive() ... try_to_swap_out() returns
   the expected result now, so things should be balanced again

4. only call deactivate_page() from generic_file_write() if we
   write "beyond the end of" the page, so partially written
   pages stay active and will remain in memory longer (8% more
   performance for dbench, as tested by Daniel Phillips)

5. (minor) s/unsigned int gfp_mask/int gfp_mask/ in vmscan.c
   ... we had both types used, which is rather inconsistent

Please consider including this patch in the next 2.4 pre-patch,
IMHO all of these things are fairly trivial and it seems to run
very nicely on my test box ;)

regards,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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


--- linux-2.4.0-test13-pre5/mm/filemap.c.orig   Thu Dec 28 19:11:39 2000
+++ linux-2.4.0-test13-pre5/mm/filemap.cThu Dec 28 19:28:06 2000
@@ -1912,7 +1912,7 @@
 
/* Make sure this doesn't exceed the process's max rss. */
error = -EIO;
-   rlim_rss = current->rlim ?  current->rlim[RLIMIT_RSS].rlim_cur :
+   rlim_rss = current->rlim ?  (current->rlim[RLIMIT_RSS].rlim_cur >> PAGE_SHIFT) 
+:
LONG_MAX; /* default: see resource.h */
if ((vma->vm_mm->rss + (end - start)) > rlim_rss)
return error;
@@ -2438,7 +2438,7 @@
}
 
while (count) {
-   unsigned long bytes, index, offset;
+   unsigned long bytes, index, offset, partial = 0;
char *kaddr;
 
/*
@@ -2448,8 +2448,10 @@
offset = (pos & (PAGE_CACHE_SIZE -1)); /* Within page */
index = pos >> PAGE_CACHE_SHIFT;
bytes = PAGE_CACHE_SIZE - offset;
-   if (bytes > count)
+   if (bytes > count) {
bytes = count;
+   partial = 1;
+   }
 
/*
 * Bring in the user page that we will copy from _first_.
@@ -2491,9 +2493,17 @@
buf += status;
}
 unlock:
-   /* Mark it unlocked again and drop the page.. */
+   /*
+* Mark it unlocked again and release the page.
+* In order to prevent large (fast) file writes
+* from causing too much memory pressure we move
+* completely written pages to the inactive list.
+* We do, however, try to keep the pages that may
+* still be written to (ie. partially written pages).
+*/
UnlockPage(page);
-   deactivate_page(page);
+   if (!partial)
+   deactivate_page(page);
page_cache_release(page);
 
    if (status < 0)
--- linux-2.4.0-test13-pre5/mm/memory.c.origThu Dec 28 19:11:39 2000
+++ linux-2.4.0-test13-pre5/mm/memory.c Thu Dec 28 19:12:04 2000
@@ -1198,6 +1198,12 @@
pgd = pgd_offset(mm, address);
pmd = pmd_alloc(pgd, address);
 
+   if (mm->rss >= (current->rlim[RLIMIT_RSS].rlim_max >> PAGE_SHIFT)) {
+   lock_kernel();
+   enforce_rss_limit(mm, GFP_HIGHUSER);
+   unlock_kernel();
+   }
+
if (pmd) {
pte_t * pte = pte_alloc(pmd, address);
if (pte)
--- linux-2.4.0-test13-pre5/mm/vmscan.c.origThu Dec 28 19:11:40 2000
+++ linux-2.4.0-test13-pre5/mm/vmscan.c Thu Dec 28 20:30:10 2000
@@ -49,7 +49,8 @@
if ((!VALID_PAGE(page)) || PageReserved(page))
goto out_failed;
 
-   if (mm->swap_cnt)
+   /* RSS trimming doesn't change the process' chances wrt. normal swap */
+   if (mm->swap_cnt && !(gfp_mask & __GFP_RSS_LIMIT))
mm->swap_cnt--;
 
onlist = PageActive(page);
@@ -58,7 +59,13 @@
age_page_up(page);
goto out_failed;
}
-   if (!onlist)
+   /*
+* SUBTLE: if the page is on the active list and we're not doing
+* RSS ulimit trimming, then we let refill_inactive_scan() take
+* care of the down aging. Always aging down here would severely
+* disadvantage shared mappings (of eg libc.so).
+*/
+   if (!onlist || (gfp_mask & __GFP_RSS_LIMIT))
/* The page is still mapped, so it can

Re: test13-pre5

[Andi Kleen]

On Thu, Dec 28, 2000 at 12:59:22PM -0800, Linus Torvalds wrote:
>  - we absolutely do _not_ want to make "struct page" bigger. We can't
>afford to just throw away another 8 bytes per page on adding a new list
>structure, I feel. Even if this would be the simplest solution.

BTW..

The current 2.4 struct page could be already shortened a lot, saving a lot
of cache.
(first number for 32bit, second for 64bit) 

- Do not compile virtual in when the kernel does not support highmem
(saves 4/8 bytes) 
- Instead of having a zone pointer mask use a 8 or 16 byte index into a 
zone table. On a modern CPU it is much cheaper to do the and/shifts than
to do even a single cache miss during page aging. On a lot of systems 
that zone index could be hardcoded to 0 anyways, giving better code.
- Instead of using 4/8 bytes for the age use only 16bit (FreeBSD which
has the same swapping algorithm even only uses 8bit) 
- Remove the waitqueue debugging (obvious @)
- flags can be __u32 on 64bit hosts, sharing 64bit with something that
is tolerant to async updates (e.g. the zone table index or the index) 
- index could be probably u32 instead of unsigned long, saving 4 bytes
on i386

Would you consider patches for any of these points? 


-Andi


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5

[Daniel Phillips]

Linus Torvalds wrote:
>  - global dirty list for global syn(). We don't have one, and I don't
>think we want one. We could add a few lists, and split up the active
>list into "active" and "active_dirty", for example, but I don't like
>the implications that would probably have for the LRU ordering.

This has been the subject of a lot of flam^H^H^H^H discussion on
#kernelnewbies about this and it's still an open question.  The only way
to see if a separate active_dirty hurts or helps is to try it.  Later.
:-)

I don't see how a separate active_dirty list can hurt LRU ordering.  We
could still take the pages off the two lists in the same order we did
with one list if we wanted to, or at least, statistically the same in
turns of number, age, time since entering the list, etc.  That better
not cause radically different or undesireable behaviour or something is
really broken.

By breaking active into two lists we'd get a very interesting tuning
parameter to play with: the relative rate at which pages are moved from
active to inactive.  Beyond that, the active_dirty list could be pressed
into service quite easily as a page-oriented version of kflushd, and
would obviously be useful as a global sync list.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: test13-pre5 (via82cxxx_audio.c)

[Jonathan Hudson]

In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> writes:
LT> 
LT> The mm cleanups also include removing "swapout()" as a VM operation, as

swapout was not removed from drivers/sound/via82cxxx_audio.c; the
following does so (compiles and produces sound, someone who
understands this please check).


--- drivers/sound/via82cxxx_audio.c.origThu Dec 28 21:02:03 2000
+++ drivers/sound/via82cxxx_audio.c Thu Dec 28 21:12:58 2000
@@ -1727,20 +1727,8 @@
 }
 
 
-#ifndef VM_RESERVE
-static int via_mm_swapout (struct page *page, struct file *filp)
-{
-   return 0;
-}
-#endif /* VM_RESERVE */
-
-
 struct vm_operations_struct via_mm_ops = {
nopage: via_mm_nopage,
-
-#ifndef VM_RESERVE
-   swapout:via_mm_swapout,
-#endif
 };
 
 
 
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Re: [wildly off-topic] Re: test13-pre5

[Marcelo Tosatti]

On Thu, 28 Dec 2000, Rik van Riel wrote:

> On Thu, 28 Dec 2000, Marcelo Tosatti wrote:
> > On Thu, 28 Dec 2000, Linus Torvalds wrote:
> > 
> > > If somebody (you? hint, hint) wants to do this,
> > 
> > Ok, I'll do it because I love Tove. 
> 
> Marcelo, you should buy some glasses ;)
> 
> Tove != Tux
> 
> It's ok and probably safe to love Tux, the nice cuddly
> penguin everybody loves.
> 
> However, loving the (6-time ??) Finnish female karate
> champion, who happens to be married to Linus is probably
> quite a bit less safe ...

Marcelo runs like hell. 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

[wildly off-topic] Re: test13-pre5

[Rik van Riel]

On Thu, 28 Dec 2000, Marcelo Tosatti wrote:
> On Thu, 28 Dec 2000, Linus Torvalds wrote:
> 
> > If somebody (you? hint, hint) wants to do this,
> 
> Ok, I'll do it because I love Tove. 

Marcelo, you should buy some glasses ;)

Tove != Tux

It's ok and probably safe to love Tux, the nice cuddly
penguin everybody loves.

However, loving the (6-time ??) Finnish female karate
champion, who happens to be married to Linus is probably
quite a bit less safe ...

cheers,

Rik
--
Hollywood goes for world dumbination,
Trailer at 11.

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/