Hi!
> Here's my first pass at a VM requirements document,
> for the embedded, desktop, and server cases. At the end is
> a summary of general rules that should take care of all of
> these cases.
>
> Bandwidth Descriptions:
>
> immediate: RAM, on-chip cache, etc.
> fast:
Hi!
Here's my first pass at a VM requirements document,
for the embedded, desktop, and server cases. At the end is
a summary of general rules that should take care of all of
these cases.
Bandwidth Descriptions:
immediate: RAM, on-chip cache, etc.
fast: Flash
On Friday 06 July 2001 21:09, Rik van Riel wrote:
> On Thu, 5 Jul 2001, Daniel Phillips wrote:
> > Let me comment on this again, having spent a couple of minutes
> > more thinking about it. Would you be happy paying 1% of your
> > battery life to get 80% less sluggish response after a memory
> >
On Thu, 5 Jul 2001, Daniel Phillips wrote:
> Let me comment on this again, having spent a couple of minutes
> more thinking about it. Would you be happy paying 1% of your
> battery life to get 80% less sluggish response after a memory
> pig exits?
Just to pull a few random numbers out of my
On Thu, 5 Jul 2001, Daniel Phillips wrote:
Let me comment on this again, having spent a couple of minutes
more thinking about it. Would you be happy paying 1% of your
battery life to get 80% less sluggish response after a memory
pig exits?
Just to pull a few random numbers out of my ass
On Friday 06 July 2001 21:09, Rik van Riel wrote:
On Thu, 5 Jul 2001, Daniel Phillips wrote:
Let me comment on this again, having spent a couple of minutes
more thinking about it. Would you be happy paying 1% of your
battery life to get 80% less sluggish response after a memory
pig
> Well, on a laptop memory and disk bandwith are rarely wasted - they cost
> battery life.
I've been playing around with different scenarios to see the differences
in performance. A good way to trigger the cache problem is to untar a
couple of kernel source trees or other large amounts of
Daniel Phillips <[EMAIL PROTECTED]> writes:
> Also, notice that the scenario we were originally discussing, the off-hours
> updatedb, doesn't normally happen on laptops because they tend to be
> suspended at that time.
No, even worse, it happens when you open the laptop for the first time
in
On Thursday 05 July 2001 17:00, Xavier Bestel wrote:
> On 05 Jul 2001 17:04:00 +0200, Daniel Phillips wrote:
> > Also, notice that the scenario we were originally discussing, the
> > off-hours updatedb, doesn't normally happen on laptops because they tend
> > to be suspended at that time.
>
>
On 05 Jul 2001 17:04:00 +0200, Daniel Phillips wrote:
> > Well, on a laptop memory and disk bandwith are rarely wasted - they cost
> > battery life.
>
> Let me comment on this again, having spent a couple of minutes more
> thinking about it. Would you be happy paying 1% of your battery life to
On Thursday 05 July 2001 16:00, Xavier Bestel wrote:
> On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote:
> > Here's an idea I just came up with while I was composing this... along
> > the lines of using unused bandwidth for something that at least has a
> > chance of being useful. Suppose we
On Thursday 05 July 2001 16:00, Xavier Bestel wrote:
> On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote:
> > Here's an idea I just came up with while I was composing this... along
> > the lines of using unused bandwidth for something that at least has a
> > chance of being useful. Suppose we
On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote:
> Here's an idea I just came up with while I was composing this... along the
> lines of using unused bandwidth for something that at least has a chance of
> being useful. Suppose we come to the end of a period of activity, the
> general
On Thursday 05 July 2001 03:49, you wrote:
> > Getting the user's "interactive" programs loaded back
> > in afterwards is a separate, much more difficult problem
> > IMHO, but no doubt still has a reasonable solution.
>
> Possibly stupid suggestion... Maybe the interactive/GUI programs should
>
On Thursday 05 July 2001 03:49, you wrote:
Getting the user's interactive programs loaded back
in afterwards is a separate, much more difficult problem
IMHO, but no doubt still has a reasonable solution.
Possibly stupid suggestion... Maybe the interactive/GUI programs should
wake up once
On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote:
Here's an idea I just came up with while I was composing this... along the
lines of using unused bandwidth for something that at least has a chance of
being useful. Suppose we come to the end of a period of activity, the
general
On Thursday 05 July 2001 16:00, Xavier Bestel wrote:
On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote:
Here's an idea I just came up with while I was composing this... along
the lines of using unused bandwidth for something that at least has a
chance of being useful. Suppose we come
On Thursday 05 July 2001 16:00, Xavier Bestel wrote:
On 05 Jul 2001 15:02:51 +0200, Daniel Phillips wrote:
Here's an idea I just came up with while I was composing this... along
the lines of using unused bandwidth for something that at least has a
chance of being useful. Suppose we come
On 05 Jul 2001 17:04:00 +0200, Daniel Phillips wrote:
Well, on a laptop memory and disk bandwith are rarely wasted - they cost
battery life.
Let me comment on this again, having spent a couple of minutes more
thinking about it. Would you be happy paying 1% of your battery life to get
On Thursday 05 July 2001 17:00, Xavier Bestel wrote:
On 05 Jul 2001 17:04:00 +0200, Daniel Phillips wrote:
Also, notice that the scenario we were originally discussing, the
off-hours updatedb, doesn't normally happen on laptops because they tend
to be suspended at that time.
Suspended !=
Daniel Phillips [EMAIL PROTECTED] writes:
Also, notice that the scenario we were originally discussing, the off-hours
updatedb, doesn't normally happen on laptops because they tend to be
suspended at that time.
No, even worse, it happens when you open the laptop for the first time
in the
Well, on a laptop memory and disk bandwith are rarely wasted - they cost
battery life.
I've been playing around with different scenarios to see the differences
in performance. A good way to trigger the cache problem is to untar a
couple of kernel source trees or other large amounts of files,
> Getting the user's "interactive" programs loaded back
> in afterwards is a separate, much more difficult problem
> IMHO, but no doubt still has a reasonable solution.
Possibly stupid suggestion... Maybe the interactive/GUI programs should wake
up once in a while and touch a couple of their
> Remember that the first message was about a laptop. At 4:00AM there's
> no activity but the updatedb one (and the other cron jobs). Simply,
> there's no 'accessed-often' data. Moreover, I'd bet that 90% of the
> metadata touched by updatedb won't be accessed at all in the future.
> Laptop
On Wednesday 04 July 2001 11:41, Marco Colombo wrote:
> On Tue, 3 Jul 2001, Daniel Phillips wrote:
> > On Tuesday 03 July 2001 12:33, Marco Colombo wrote:
> > > Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only
> > > when background aging, maybe it's not enough to keep processes
On Wednesday 04 July 2001 10:32, Marco Colombo wrote:
> On Tue, 3 Jul 2001, Daniel Phillips wrote:
> > On Monday 02 July 2001 20:42, Rik van Riel wrote:
> > > On Thu, 28 Jun 2001, Marco Colombo wrote:
> > > > I'm not sure that, in general, recent pages with only one access are
> > > > still
On Tue, 3 Jul 2001, Daniel Phillips wrote:
> On Tuesday 03 July 2001 12:33, Marco Colombo wrote:
> > Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only
> > when background aging, maybe it's not enough to keep processes like
> > updatedb from causing interactive pages to be
On Tue, 3 Jul 2001, Daniel Phillips wrote:
> On Monday 02 July 2001 20:42, Rik van Riel wrote:
> > On Thu, 28 Jun 2001, Marco Colombo wrote:
> > > I'm not sure that, in general, recent pages with only one access are
> > > still better eviction candidates compared to 8 hours old pages. Here
> > >
On Tue, 3 Jul 2001, Daniel Phillips wrote:
> And by the way, this is just brainstorming, it hasn't reached the 'proposal'
> stage yet.
So while we're here, an idea someone proposed in #debian while discussion this
thread ([EMAIL PROTECTED], you know who you are): QoS for application paging
on
On Tue, 3 Jul 2001, Daniel Phillips wrote:
And by the way, this is just brainstorming, it hasn't reached the 'proposal'
stage yet.
So while we're here, an idea someone proposed in #debian while discussion this
thread ([EMAIL PROTECTED], you know who you are): QoS for application paging
on
On Tue, 3 Jul 2001, Daniel Phillips wrote:
On Monday 02 July 2001 20:42, Rik van Riel wrote:
On Thu, 28 Jun 2001, Marco Colombo wrote:
I'm not sure that, in general, recent pages with only one access are
still better eviction candidates compared to 8 hours old pages. Here
we need
On Tue, 3 Jul 2001, Daniel Phillips wrote:
On Tuesday 03 July 2001 12:33, Marco Colombo wrote:
Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only
when background aging, maybe it's not enough to keep processes like
updatedb from causing interactive pages to be evicted.
On Wednesday 04 July 2001 10:32, Marco Colombo wrote:
On Tue, 3 Jul 2001, Daniel Phillips wrote:
On Monday 02 July 2001 20:42, Rik van Riel wrote:
On Thu, 28 Jun 2001, Marco Colombo wrote:
I'm not sure that, in general, recent pages with only one access are
still better eviction
On Wednesday 04 July 2001 11:41, Marco Colombo wrote:
On Tue, 3 Jul 2001, Daniel Phillips wrote:
On Tuesday 03 July 2001 12:33, Marco Colombo wrote:
Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only
when background aging, maybe it's not enough to keep processes like
Remember that the first message was about a laptop. At 4:00AM there's
no activity but the updatedb one (and the other cron jobs). Simply,
there's no 'accessed-often' data. Moreover, I'd bet that 90% of the
metadata touched by updatedb won't be accessed at all in the future.
Laptop users
Getting the user's interactive programs loaded back
in afterwards is a separate, much more difficult problem
IMHO, but no doubt still has a reasonable solution.
Possibly stupid suggestion... Maybe the interactive/GUI programs should wake
up once in a while and touch a couple of their pages?
On Monday 02 July 2001 20:42, Rik van Riel wrote:
> On Thu, 28 Jun 2001, Marco Colombo wrote:
> > I'm not sure that, in general, recent pages with only one access are
> > still better eviction candidates compared to 8 hours old pages. Here
> > we need either another way to detect one-shot
An ammendment to my previous post...
> I see three page priority levels:
>
> 0 - accessed-never/aged to zero
> 1 - accessed-once/just loaded
> 2 - accessed-often
>
> with these transitions:
>
> 0 -> 1, if a page is accessed
> 1 -> 2, if a page is accessed a second time
> 1 -> 0, if a
On Tuesday 03 July 2001 12:33, Marco Colombo wrote:
> Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only
> when background aging, maybe it's not enough to keep processes like
> updatedb from causing interactive pages to be evicted.
> That's why I said we should have another way
On Mon, 2 Jul 2001, Rik van Riel wrote:
> On Thu, 28 Jun 2001, Marco Colombo wrote:
>
> > I'm not sure that, in general, recent pages with only one access are
> > still better eviction candidates compared to 8 hours old pages. Here
> > we need either another way to detect one-shot activity (like
On Mon, 2 Jul 2001, Rik van Riel wrote:
On Thu, 28 Jun 2001, Marco Colombo wrote:
I'm not sure that, in general, recent pages with only one access are
still better eviction candidates compared to 8 hours old pages. Here
we need either another way to detect one-shot activity (like the one
On Tuesday 03 July 2001 12:33, Marco Colombo wrote:
Oh, yes, since that PAGE_AGE_BG_INTERACTIVE_MINIMUM is applied only
when background aging, maybe it's not enough to keep processes like
updatedb from causing interactive pages to be evicted.
That's why I said we should have another way to
An ammendment to my previous post...
I see three page priority levels:
0 - accessed-never/aged to zero
1 - accessed-once/just loaded
2 - accessed-often
with these transitions:
0 - 1, if a page is accessed
1 - 2, if a page is accessed a second time
1 - 0, if a page gets old
On Monday 02 July 2001 20:42, Rik van Riel wrote:
On Thu, 28 Jun 2001, Marco Colombo wrote:
I'm not sure that, in general, recent pages with only one access are
still better eviction candidates compared to 8 hours old pages. Here
we need either another way to detect one-shot activity (like
On Thu, 28 Jun 2001, Marco Colombo wrote:
> I'm not sure that, in general, recent pages with only one access are
> still better eviction candidates compared to 8 hours old pages. Here
> we need either another way to detect one-shot activity (like the one
> performed by updatedb),
Fully agreed,
Hi,
> My laptop has 256mb of ram,
> but every day
> it runs the updatedb for locate.
The remedy here is simple: Do not run updatedb from cron,
but only when you made changes.
Greetings,
Jens
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi,
My laptop has 256mb of ram,
but every day
it runs the updatedb for locate.
The remedy here is simple: Do not run updatedb from cron,
but only when you made changes.
Greetings,
Jens
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Thu, 28 Jun 2001, Marco Colombo wrote:
I'm not sure that, in general, recent pages with only one access are
still better eviction candidates compared to 8 hours old pages. Here
we need either another way to detect one-shot activity (like the one
performed by updatedb),
Fully agreed, but
[...]
> immediate: RAM, on-chip cache, etc.
> fast: Flash reads, ROMs, etc.
> medium:Hard drives, CD-ROMs, 100Mb ethernet, etc.
> slow: Flash writes, floppy disks, CD-WR burners
> packeted: Reads/write should be in as large a packet as possible
>
On Thu, 28 Jun 2001, Daniel Phillips wrote:
> On Thursday 28 June 2001 14:20, [EMAIL PROTECTED] wrote:
> > > If individual pages could be classified as code (text segments),
> > > data, file cache, and so on, I would specify costs to the paging
> > > of such pages in or out. This way I can make
On Thursday 28 June 2001 17:21, Jonathan Morton wrote:
> >There is a simple change in strategy that will fix up the updatedb case
> > quite nicely, it goes something like this: a single access to a page
> > (e.g., reading it) isn't enough to bring it to the front of the LRU
> > queue, but
>There is a simple change in strategy that will fix up the updatedb case quite
>nicely, it goes something like this: a single access to a page (e.g., reading
>it) isn't enough to bring it to the front of the LRU queue, but accessing it
>twice or more is. This is being looked at.
Say, when a
On Thursday 28 June 2001 15:37, Alan Cox wrote:
> > The problem with updatedb is that it pushes all applications to the swap,
> > and when you get back in the morning, everything has to be paged back
> > from swap just because the (stupid) OS is prepared for yet another
> > updatedb run.
>
>
On Thursday 28 June 2001 14:20, [EMAIL PROTECTED] wrote:
> > If individual pages could be classified as code (text segments),
> > data, file cache, and so on, I would specify costs to the paging
> > of such pages in or out. This way I can make the system perfer
> > to drop a file cache page that
> > Updatedb is a bit odd in that it mostly sucks in metadata and the buffer to
> > page cache balancing is a bit suspect IMHO.
>
> In 2.4.6-pre, the buffer cache is no longer used for metata, right?
For ext2 directory blocks the page cache is now used
-
To unsubscribe from this list: send the
On Thu, 28 Jun 2001, Alan Cox wrote:
> > > That isnt really down to labelling pages, what you are talking qbout is what
> > > you get for free when page aging works right (eg 2.0.39) but don't get in
> > > 2.2 - and don't yet (although its coming) quite get right in 2.4.6pre.
> >
> > Correct,
> > That isnt really down to labelling pages, what you are talking qbout is what
> > you get for free when page aging works right (eg 2.0.39) but don't get in
> > 2.2 - and don't yet (although its coming) quite get right in 2.4.6pre.
>
> Correct, but all pages are not equal.
That is the whole
On Thu, 28 Jun 2001, Alan Cox wrote:
> > This would be extremely useful. My laptop has 256mb of ram, but every day
> > it runs the updatedb for locate. This fills the memory with the file
> > cache. Interactivity is then terrible, and swap is unnecessarily used. On
> > the laptop all this hard
Stefan Hoffmeister <[EMAIL PROTECTED]> writes:
[...]
> Windows NT/2000 has flags that can be for each CreateFile operation
> ("open" in Unix terms), for instance
>
> FILE_ATTRIBUTE_TEMPORARY
>
> FILE_FLAG_WRITE_THROUGH
> FILE_FLAG_NO_BUFFERING
> FILE_FLAG_RANDOM_ACCESS
>
On 28 Jun 2001, Xavier Bestel wrote:
> On 28 Jun 2001 14:02:09 +0200, Tobias Ringstrom wrote:
>
> > This would be very useful, I think. Would it be very hard to classify
> > pages like this (text/data/cache/...)?
>
> How would you classify a page of perl code ?
I do know how the Perl
On 28 Jun 2001 14:02:09 +0200, Tobias Ringstrom wrote:
> This would be very useful, I think. Would it be very hard to classify
> pages like this (text/data/cache/...)?
How would you classify a page of perl code ?
Xav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> This would be extremely useful. My laptop has 256mb of ram, but every day
> it runs the updatedb for locate. This fills the memory with the file
> cache. Interactivity is then terrible, and swap is unnecessarily used. On
> the laptop all this hard drive thrashing is bad news for battery life
> If individual pages could be classified as code (text segments),
> data, file cache, and so on, I would specify costs to the paging
> of such pages in or out. This way I can make the system perfer
> to drop a file cache page that has not been accessed for five
> minutes, over a program
On Thu, 28 Jun 2001, Helge Hafting wrote:
> Preventing swap-trashing at all cost doesn't help if the
> machine loose to io-trashing instead. Performance will be
> just as much down, although perhaps more satisfying because
> people aren't that surprised if explicit file operations
> take a long
Helge Hafting wrote:
>
> Martin Knoblauch wrote:
>
> >
> > maybe more specific: If the hit-rate is low and the cache is already
> > 70+% of the systems memory, the chances maybe slim that more cache is
> > going to improve the hit-rate.
> >
> Oh, but this is posible. You can get into
Martin Knoblauch wrote:
>
> maybe more specific: If the hit-rate is low and the cache is already
> 70+% of the systems memory, the chances maybe slim that more cache is
> going to improve the hit-rate.
>
Oh, but this is posible. You can get into situations where
the (file cache) working set
Rik van Riel wrote:
>
> On Wed, 27 Jun 2001, Martin Knoblauch wrote:
>
> > I do not care much whether the cache is using 99% of the systems memory
> > or 50%. As long as there is free memory, using it for cache is great. I
> > care a lot if the cache takes down interactivity, because it pushes
Rik van Riel wrote:
On Wed, 27 Jun 2001, Martin Knoblauch wrote:
I do not care much whether the cache is using 99% of the systems memory
or 50%. As long as there is free memory, using it for cache is great. I
care a lot if the cache takes down interactivity, because it pushes out
Martin Knoblauch wrote:
maybe more specific: If the hit-rate is low and the cache is already
70+% of the systems memory, the chances maybe slim that more cache is
going to improve the hit-rate.
Oh, but this is posible. You can get into situations where
the (file cache) working set needs
Helge Hafting wrote:
Martin Knoblauch wrote:
maybe more specific: If the hit-rate is low and the cache is already
70+% of the systems memory, the chances maybe slim that more cache is
going to improve the hit-rate.
Oh, but this is posible. You can get into situations where
the
On Thu, 28 Jun 2001, Helge Hafting wrote:
Preventing swap-trashing at all cost doesn't help if the
machine loose to io-trashing instead. Performance will be
just as much down, although perhaps more satisfying because
people aren't that surprised if explicit file operations
take a long time.
If individual pages could be classified as code (text segments),
data, file cache, and so on, I would specify costs to the paging
of such pages in or out. This way I can make the system perfer
to drop a file cache page that has not been accessed for five
minutes, over a program text
On 28 Jun 2001 14:02:09 +0200, Tobias Ringstrom wrote:
This would be very useful, I think. Would it be very hard to classify
pages like this (text/data/cache/...)?
How would you classify a page of perl code ?
Xav
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
On 28 Jun 2001, Xavier Bestel wrote:
On 28 Jun 2001 14:02:09 +0200, Tobias Ringstrom wrote:
This would be very useful, I think. Would it be very hard to classify
pages like this (text/data/cache/...)?
How would you classify a page of perl code ?
I do know how the Perl interpreter
Stefan Hoffmeister [EMAIL PROTECTED] writes:
[...]
Windows NT/2000 has flags that can be for each CreateFile operation
(open in Unix terms), for instance
FILE_ATTRIBUTE_TEMPORARY
FILE_FLAG_WRITE_THROUGH
FILE_FLAG_NO_BUFFERING
FILE_FLAG_RANDOM_ACCESS
On Thursday 28 June 2001 14:20, [EMAIL PROTECTED] wrote:
If individual pages could be classified as code (text segments),
data, file cache, and so on, I would specify costs to the paging
of such pages in or out. This way I can make the system perfer
to drop a file cache page that has not
On Thursday 28 June 2001 15:37, Alan Cox wrote:
The problem with updatedb is that it pushes all applications to the swap,
and when you get back in the morning, everything has to be paged back
from swap just because the (stupid) OS is prepared for yet another
updatedb run.
Updatedb is a
There is a simple change in strategy that will fix up the updatedb case quite
nicely, it goes something like this: a single access to a page (e.g., reading
it) isn't enough to bring it to the front of the LRU queue, but accessing it
twice or more is. This is being looked at.
Say, when a page is
On Thursday 28 June 2001 17:21, Jonathan Morton wrote:
There is a simple change in strategy that will fix up the updatedb case
quite nicely, it goes something like this: a single access to a page
(e.g., reading it) isn't enough to bring it to the front of the LRU
queue, but accessing it
On Thu, 28 Jun 2001, Daniel Phillips wrote:
On Thursday 28 June 2001 14:20, [EMAIL PROTECTED] wrote:
If individual pages could be classified as code (text segments),
data, file cache, and so on, I would specify costs to the paging
of such pages in or out. This way I can make the
[...]
immediate: RAM, on-chip cache, etc.
fast: Flash reads, ROMs, etc.
medium:Hard drives, CD-ROMs, 100Mb ethernet, etc.
slow: Flash writes, floppy disks, CD-WR burners
packeted: Reads/write should be in as large a packet as possible
Updatedb is a bit odd in that it mostly sucks in metadata and the buffer to
page cache balancing is a bit suspect IMHO.
In 2.4.6-pre, the buffer cache is no longer used for metata, right?
For ext2 directory blocks the page cache is now used
-
To unsubscribe from this list: send the line
On Thu, 28 Jun 2001, Alan Cox wrote:
This would be extremely useful. My laptop has 256mb of ram, but every day
it runs the updatedb for locate. This fills the memory with the file
cache. Interactivity is then terrible, and swap is unnecessarily used. On
the laptop all this hard drive
On Thu, 28 Jun 2001, Alan Cox wrote:
That isnt really down to labelling pages, what you are talking qbout is what
you get for free when page aging works right (eg 2.0.39) but don't get in
2.2 - and don't yet (although its coming) quite get right in 2.4.6pre.
Correct, but all pages
That isnt really down to labelling pages, what you are talking qbout is what
you get for free when page aging works right (eg 2.0.39) but don't get in
2.2 - and don't yet (although its coming) quite get right in 2.4.6pre.
Correct, but all pages are not equal.
That is the whole point of
This would be extremely useful. My laptop has 256mb of ram, but every day
it runs the updatedb for locate. This fills the memory with the file
cache. Interactivity is then terrible, and swap is unnecessarily used. On
the laptop all this hard drive thrashing is bad news for battery life
On Wed, 27 Jun 2001, Martin Knoblauch wrote:
> I do not care much whether the cache is using 99% of the systems memory
> or 50%. As long as there is free memory, using it for cache is great. I
> care a lot if the cache takes down interactivity, because it pushes out
> processes that it thinks
> Rik> ... but I fail to see this one. If we get a low cache hit rate,
> Rik> couldn't that just mean we allocated too little memory for the
> Rik> cache ?
> Or that we're doing big sequential reads of file(s) which are larger
> than memory, in which case expanding the cache size buys us
On Tue, 26 Jun 2001, Rik van Riel wrote:
> On Tue, 26 Jun 2001, John Stoffel wrote:
>
> > >> * If we're getting low cache hit rates, don't flush
> > >> processes to swap.
> > >> * If we're getting good cache hit rates, flush old, idle
> > >> processes to swap.
> >
> > Rik> ... but I fail to see
On 26 Jun 2001 20:43:33 -0400, Dan Maas wrote:
> > Windows NT/2000 has flags that can be for each CreateFile operation
> > ("open" in Unix terms), for instance
> >
> > FILE_ATTRIBUTE_TEMPORARY
> > FILE_FLAG_WRITE_THROUGH
> > FILE_FLAG_NO_BUFFERING
> > FILE_FLAG_RANDOM_ACCESS
> >
>> * If we're getting low cache hit rates, don't flush
>> processes to swap.
>> * If we're getting good cache hit rates, flush old, idle
>> processes to swap.
Rik> ... but I fail to see this one. If we get a low cache hit rate,
Rik> couldn't that just mean we allocated too little memory for
* If we're getting low cache hit rates, don't flush
processes to swap.
* If we're getting good cache hit rates, flush old, idle
processes to swap.
Rik ... but I fail to see this one. If we get a low cache hit rate,
Rik couldn't that just mean we allocated too little memory for the
Rik
On 26 Jun 2001 20:43:33 -0400, Dan Maas wrote:
Windows NT/2000 has flags that can be for each CreateFile operation
(open in Unix terms), for instance
FILE_ATTRIBUTE_TEMPORARY
FILE_FLAG_WRITE_THROUGH
FILE_FLAG_NO_BUFFERING
FILE_FLAG_RANDOM_ACCESS
FILE_FLAG_SEQUENTIAL_SCAN
On Tue, 26 Jun 2001, Rik van Riel wrote:
On Tue, 26 Jun 2001, John Stoffel wrote:
* If we're getting low cache hit rates, don't flush
processes to swap.
* If we're getting good cache hit rates, flush old, idle
processes to swap.
Rik ... but I fail to see this one. If we get a
Rik ... but I fail to see this one. If we get a low cache hit rate,
Rik couldn't that just mean we allocated too little memory for the
Rik cache ?
Or that we're doing big sequential reads of file(s) which are larger
than memory, in which case expanding the cache size buys us nothing,
and
On Wed, 27 Jun 2001, Martin Knoblauch wrote:
I do not care much whether the cache is using 99% of the systems memory
or 50%. As long as there is free memory, using it for cache is great. I
care a lot if the cache takes down interactivity, because it pushes out
processes that it thinks idle,
> I personally don't feel that the cache should be allowed to grow over
> 50% of the system's memory at all, we've got so much in the cache at
> that point, that we're probably not hitting it all that much.
That depends very much on what you're using the system for. Suppose you're
running a
On Tue, Jun 26, 2001 at 08:43:33PM -0400, Dan Maas wrote:
> (hrm, maybe I could hack up my own manual read-ahead/drop-behind with mmap()
> and memory locking...)
Just to argue portability for a moment (portability on the expected
results, that is, vs APIs).
Would this technique work across a
> Windows NT/2000 has flags that can be for each CreateFile operation
> ("open" in Unix terms), for instance
>
> FILE_ATTRIBUTE_TEMPORARY
> FILE_FLAG_WRITE_THROUGH
> FILE_FLAG_NO_BUFFERING
> FILE_FLAG_RANDOM_ACCESS
> FILE_FLAG_SEQUENTIAL_SCAN
>
There is a BSD-originated convention for
On Tue, Jun 26, 2001 at 03:48:09PM -0700, Jeffrey W. Baker wrote:
> These flags would be really handy. We already have the raw device for
> sequential reading of e.g. CDROM and DVD devices.
Not going to help 99% of the applications out there.
mrc
--
Mike Castle [EMAIL PROTECTED]
1 - 100 of 118 matches
Mail list logo
