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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
hrough 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 w
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,
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
s 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 past
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
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
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 n
, 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 -t
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-te
> 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 con
, 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
-t
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 Tje
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
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
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
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
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 shortw
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://dis
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
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
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
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
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
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. :)
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
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,
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,
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
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. :)
---
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
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
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
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,
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
ple 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:
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
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
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
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
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
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 Tje
, 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
-t
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 f
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
, 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 -t
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 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
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
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.
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
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
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);
>
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
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
>
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
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
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 ?
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 -
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
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
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
>
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
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
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
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
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_
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
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
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
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
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
1 - 100 of 130 matches
Mail list logo
