Hi,
* "Linus" == Linus Torvalds <[EMAIL PROTECTED]> writes:
[...]
> Almost nothing does that. innd is (sadly) the only regular thing that uses
> this, which is why it's always innd that breaks, even if everything else
> works.
> And even innd is often compiled to use "write()" instead of
Hi,
* "Linus" == Linus Torvalds [EMAIL PROTECTED] writes:
[...]
Almost nothing does that. innd is (sadly) the only regular thing that uses
this, which is why it's always innd that breaks, even if everything else
works.
And even innd is often compiled to use "write()" instead of shared
Chris Wedgwood <[EMAIL PROTECTED]> writes:
> I would prefer we leave ramfs alone as is -- it makes an excellent
> starting point for a new fs and is fairly simple to grok. If we are
> to add any more complexity here like the size limiting patches or the
> use of a backing store, I'd like to have
Chris Wedgwood [EMAIL PROTECTED] writes:
I would prefer we leave ramfs alone as is -- it makes an excellent
starting point for a new fs and is fairly simple to grok. If we are
to add any more complexity here like the size limiting patches or the
use of a backing store, I'd like to have this
On Thu, 28 Dec 2000, Alan Cox wrote:
> The ramfs maintainer has patches (in -ac) which deal with the size limiting
> of RAMfs. I'm using it on a PDA and its really really nice to be able to
> pop up a GUI app and drag the bar to '60% for apps' like other PDA systems ;)
May I ask which PDA do
Linus Torvalds wrote:
> Ok, pre-5 should have all the same places you found already fixed, but
> please do give it some heavy-duty testing to make sure there isn't
> anything hidden..
I've beaten on it fairly heavily with the BUG in there as you suggested,
with no problems.
This kernel even
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> does anyone other than me think that the pm code is *way* too agressive about
> spinning down the hard drive? my 256mb laptop (2.2.16) will only spin down the
> disk for about 30 seconds before it decides it's got something else it feels
>
On Thu, 28 Dec 2000, Daniel Phillips wrote:
>
> OK, I see you just posted -pre5 while I was making the patch, but here
> it is anyway, as a cross-check.
Ok, pre-5 should have all the same places you found already fixed, but
please do give it some heavy-duty testing to make sure there isn't
Linus Torvalds wrote:
> We don't want to lose dirty bits by mistake. The only cases where it's ok
> to clear the dirty bit is when we truncate a page completely (so it won't
> be needed and obviously really shouldn't be written out) and when we've
> lost the last user of a swap cache entry.
>
>
Linus Torvalds wrote:
> No, I'd much rather have
>
> if (PageDirty(page)) BUG();
>
> there, and then have the free_swap_cache code clear the dirty bit.
>
> We don't want to lose dirty bits by mistake. The only cases where it's ok
> to clear the dirty bit is when we truncate a page
> > I use ramfs for /tmp on my laptop -- it's very handy because it
> > extends the amount of the the disk had spent spun down and therefore
> > battery life; but writing large files into /tmp can blow away the
> > system or at the very least eat away at otherwise usable ram. Not
> > terribly
On Thu, 28 Dec 2000, Daniel Phillips wrote:
> [in vmscan.c]
> > Between line 573 and 594 the page can have 1 user and be unlocked, so it
> > can be removed by invalidate_inode_pages, and the mapping will be
> > cleared here:
> >
On Thu, 28 Dec 2000, Chris Wedgwood wrote:
>
> this remind me; perhaps you or Al could answer this.
>
> How hard would it be to have ramfs backed by swap? The goal being
> try to achieve something like a FreeBSDs mfs.
>
> I use ramfs for /tmp on my laptop -- it's very handy because it
>
[in vmscan.c]
> Between line 573 and 594 the page can have 1 user and be unlocked, so it
> can be removed by invalidate_inode_pages, and the mapping will be
> cleared here:
> http://innominate.org/~graichen/projects/lxr/source/mm/filemap.c?v=v2.3#L98
This seems like the obvious thing to do:
---
On Thursday, December 28, 2000 15:51:24 -0200 Rik van Riel
<[EMAIL PROTECTED]> wrote:
> On Thu, 28 Dec 2000, Chris Mason wrote:
>
>> I think a dirty page without a writepage func seems a bit
>> broken. How about we give ramfs a writepage func that just
>> returns 1. That way nobody does any
On Thu, 28 Dec 2000, Linus Torvalds wrote:
> On Thu, 28 Dec 2000, Rik van Riel wrote:
> >
> > I've made a small debugging patch that simply checks
> > for this illegal state in add_page_to_active_list and
> > add_page_to_inactive_dirty_list.
>
> I bet it won't catch the real bad guy, which
On Thu, 28 Dec 2000, Chris Mason wrote:
> I think a dirty page without a writepage func seems a bit
> broken. How about we give ramfs a writepage func that just
> returns 1. That way nobody does any special if
> (ramfs_page(page)) kinds of tests...
This will lead to the ramfs pages staying on
On Thu, 28 Dec 2000, Daniel Phillips wrote:
>
> It's logical that PageDirty should never be get for ramfs, and a ramfs
> page should never have buffers on it.
What?
No no no.
You're obviously right that ramfs will never have buffers on the page, but
why shouldn't a ramfs page be dirty?
Of
On Thursday, December 28, 2000 16:15:48 +0100 Daniel Phillips
<[EMAIL PROTECTED]> wrote:
> On Thu, 28 Dec 2000, Rik van Riel wrote:
>> On Thu, 28 Dec 2000, Daniel Phillips wrote:
>>
>> > It's logical that PageDirty should never be get for ramfs,
>>
>> No. Not setting PageDirty will cause the
On Thu, 28 Dec 2000, Rik van Riel wrote:
>
> I've made a small debugging patch that simply checks
> for this illegal state in add_page_to_active_list and
> add_page_to_inactive_dirty_list.
I bet it won't catch the real bad guy, which almost certainly is the
"remove_from_swap_cache()" thing
Rik van Riel wrote:
>
> On Thu, 28 Dec 2000, Rik van Riel wrote:
> > On Wed, 27 Dec 2000, Linus Torvalds wrote:
> > > On Wed, 27 Dec 2000, Rik van Riel wrote:
> > > >
> > > > The (trivial) patch below should fix this problem.
> > >
> > > It must be wrong.
> > >
> > > If we have a dirty page on
On Thu, 28 Dec 2000, Rik van Riel wrote:
> On Thu, 28 Dec 2000, Daniel Phillips wrote:
>
> > It's logical that PageDirty should never be get for ramfs,
>
> No. Not setting PageDirty will cause the system to move the
> page to the inactive_clean list and happily reclaim your data.
>
> We _have
On Thu, 28 Dec 2000, Daniel Phillips wrote:
> It's logical that PageDirty should never be get for ramfs,
No. Not setting PageDirty will cause the system to move the
page to the inactive_clean list and happily reclaim your data.
We _have to_ use something like PageDirty for this, and
checking
Linus Torvalds wrote:
>
> On Wed, 27 Dec 2000, Philipp Rumpf wrote:
>
> > On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
> > > It must be wrong.
> > >
> > > If we have a dirty page on the LRU lists, that page _must_ have a mapping.
> >
> > What about pages with a mapping but
On Thu, 28 Dec 2000, Rik van Riel wrote:
> On Wed, 27 Dec 2000, Linus Torvalds wrote:
> > On Wed, 27 Dec 2000, Rik van Riel wrote:
> > >
> > > The (trivial) patch below should fix this problem.
> >
> > It must be wrong.
> >
> > If we have a dirty page on the LRU lists, that page _must_ have
>
Zlatko Calusic wrote:
>
> Rik van Riel <[EMAIL PROTECTED]> writes:
>
> > On Mon, 25 Dec 2000, Dan Aloni wrote:
> > > On 25 Dec 2000, Zlatko Calusic wrote:
> > >
> > > > Speaking of page_launder() I just stumbled upon two oopsen today on
> > > > the UP build. Maybe it could give a hint to someone,
On Wed, 27 Dec 2000, Linus Torvalds wrote:
> On Wed, 27 Dec 2000, Rik van Riel wrote:
> >
> > The (trivial) patch below should fix this problem.
>
> It must be wrong.
>
> If we have a dirty page on the LRU lists, that page _must_ have
> a mapping.
Hmm, last I looked buffercache pages didn't
> does anyone other than me think that the pm code is *way* too agressive about
> spinning down the hard drive? my 256mb laptop (2.2.16) will only spin down the
> disk for about 30 seconds before it decides it's got something else it feels
> like writing out, and spins back up. Spinnup has got to
does anyone other than me think that the pm code is *way* too agressive about
spinning down the hard drive? my 256mb laptop (2.2.16) will only spin down the
disk for about 30 seconds before it decides it's got something else it feels
like writing out, and spins back up. Spinnup has got to be
On Wed, 27 Dec 2000, Linus Torvalds wrote:
On Wed, 27 Dec 2000, Rik van Riel wrote:
The (trivial) patch below should fix this problem.
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have
a mapping.
Hmm, last I looked buffercache pages didn't have
Zlatko Calusic wrote:
Rik van Riel [EMAIL PROTECTED] writes:
On Mon, 25 Dec 2000, Dan Aloni wrote:
On 25 Dec 2000, Zlatko Calusic wrote:
Speaking of page_launder() I just stumbled upon two oopsen today on
the UP build. Maybe it could give a hint to someone, I'm not that good
On Thu, 28 Dec 2000, Rik van Riel wrote:
On Wed, 27 Dec 2000, Linus Torvalds wrote:
On Wed, 27 Dec 2000, Rik van Riel wrote:
The (trivial) patch below should fix this problem.
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have
a mapping.
Linus Torvalds wrote:
On Wed, 27 Dec 2000, Philipp Rumpf wrote:
On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What about pages with a mapping but without a writepage
On Thu, 28 Dec 2000, Daniel Phillips wrote:
It's logical that PageDirty should never be get for ramfs,
No. Not setting PageDirty will cause the system to move the
page to the inactive_clean list and happily reclaim your data.
We _have to_ use something like PageDirty for this, and
checking
On Thu, 28 Dec 2000, Rik van Riel wrote:
On Thu, 28 Dec 2000, Daniel Phillips wrote:
It's logical that PageDirty should never be get for ramfs,
No. Not setting PageDirty will cause the system to move the
page to the inactive_clean list and happily reclaim your data.
We _have to_ use
Rik van Riel wrote:
On Thu, 28 Dec 2000, Rik van Riel wrote:
On Wed, 27 Dec 2000, Linus Torvalds wrote:
On Wed, 27 Dec 2000, Rik van Riel wrote:
The (trivial) patch below should fix this problem.
It must be wrong.
If we have a dirty page on the LRU lists, that page
On Thu, 28 Dec 2000, Rik van Riel wrote:
I've made a small debugging patch that simply checks
for this illegal state in add_page_to_active_list and
add_page_to_inactive_dirty_list.
I bet it won't catch the real bad guy, which almost certainly is the
"remove_from_swap_cache()" thing (it
On Thursday, December 28, 2000 16:15:48 +0100 Daniel Phillips
[EMAIL PROTECTED] wrote:
On Thu, 28 Dec 2000, Rik van Riel wrote:
On Thu, 28 Dec 2000, Daniel Phillips wrote:
It's logical that PageDirty should never be get for ramfs,
No. Not setting PageDirty will cause the system to
On Thu, 28 Dec 2000, Daniel Phillips wrote:
It's logical that PageDirty should never be get for ramfs, and a ramfs
page should never have buffers on it.
What?
No no no.
You're obviously right that ramfs will never have buffers on the page, but
why shouldn't a ramfs page be dirty?
Of
On Thu, 28 Dec 2000, Chris Mason wrote:
I think a dirty page without a writepage func seems a bit
broken. How about we give ramfs a writepage func that just
returns 1. That way nobody does any special if
(ramfs_page(page)) kinds of tests...
This will lead to the ramfs pages staying on the
On Thu, 28 Dec 2000, Linus Torvalds wrote:
On Thu, 28 Dec 2000, Rik van Riel wrote:
I've made a small debugging patch that simply checks
for this illegal state in add_page_to_active_list and
add_page_to_inactive_dirty_list.
I bet it won't catch the real bad guy, which almost
On Thursday, December 28, 2000 15:51:24 -0200 Rik van Riel
[EMAIL PROTECTED] wrote:
On Thu, 28 Dec 2000, Chris Mason wrote:
I think a dirty page without a writepage func seems a bit
broken. How about we give ramfs a writepage func that just
returns 1. That way nobody does any special
[in vmscan.c]
Between line 573 and 594 the page can have 1 user and be unlocked, so it
can be removed by invalidate_inode_pages, and the mapping will be
cleared here:
http://innominate.org/~graichen/projects/lxr/source/mm/filemap.c?v=v2.3#L98
This seems like the obvious thing to do:
---
On Thu, 28 Dec 2000, Chris Wedgwood wrote:
this remind me; perhaps you or Al could answer this.
How hard would it be to have ramfs backed by swap? The goal being
try to achieve something like a FreeBSDs mfs.
I use ramfs for /tmp on my laptop -- it's very handy because it
extends
On Thu, 28 Dec 2000, Daniel Phillips wrote:
[in vmscan.c]
Between line 573 and 594 the page can have 1 user and be unlocked, so it
can be removed by invalidate_inode_pages, and the mapping will be
cleared here:
I use ramfs for /tmp on my laptop -- it's very handy because it
extends the amount of the the disk had spent spun down and therefore
battery life; but writing large files into /tmp can blow away the
system or at the very least eat away at otherwise usable ram. Not
terribly desirable.
Linus Torvalds wrote:
No, I'd much rather have
if (PageDirty(page)) BUG();
there, and then have the free_swap_cache code clear the dirty bit.
We don't want to lose dirty bits by mistake. The only cases where it's ok
to clear the dirty bit is when we truncate a page completely
Linus Torvalds wrote:
We don't want to lose dirty bits by mistake. The only cases where it's ok
to clear the dirty bit is when we truncate a page completely (so it won't
be needed and obviously really shouldn't be written out) and when we've
lost the last user of a swap cache entry.
Any
On Thu, 28 Dec 2000, Daniel Phillips wrote:
OK, I see you just posted -pre5 while I was making the patch, but here
it is anyway, as a cross-check.
Ok, pre-5 should have all the same places you found already fixed, but
please do give it some heavy-duty testing to make sure there isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
does anyone other than me think that the pm code is *way* too agressive about
spinning down the hard drive? my 256mb laptop (2.2.16) will only spin down the
disk for about 30 seconds before it decides it's got something else it feels
On Thu, 28 Dec 2000, Alan Cox wrote:
The ramfs maintainer has patches (in -ac) which deal with the size limiting
of RAMfs. I'm using it on a PDA and its really really nice to be able to
pop up a GUI app and drag the bar to '60% for apps' like other PDA systems ;)
May I ask which PDA do you
On Thu, 28 Dec 2000, Chris Wedgwood wrote:
> (cc' list trimmed)
[further]
> I use ramfs for /tmp on my laptop -- it's very handy because it
> extends the amount of the the disk had spent spun down and therefore
> battery life; but writing large files into /tmp can blow away the
> system or at
On Thu, 28 Dec 2000, Dan Aloni wrote:
> On Wed, 27 Dec 2000, Philipp Rumpf wrote:
>
> > On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
> > > It must be wrong.
> > >
> > > If we have a dirty page on the LRU lists, that page _must_ have a mapping.
> >
> > What about pages with
On Wed, 27 Dec 2000, Philipp Rumpf wrote:
> On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
> > It must be wrong.
> >
> > If we have a dirty page on the LRU lists, that page _must_ have a mapping.
>
> What about pages with a mapping but without a writepage function ? or pages
>
On Wed, 27 Dec 2000, Philipp Rumpf wrote:
> On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
> > It must be wrong.
> >
> > If we have a dirty page on the LRU lists, that page _must_ have a mapping.
>
> What about pages with a mapping but without a writepage function ? or pages
On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
> It must be wrong.
>
> If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What about pages with a mapping but without a writepage function ? or pages
whose writepage function fails ? The current code seems
On Wed, 27 Dec 2000, Rik van Riel wrote:
>
> The (trivial) patch below should fix this problem.
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What semantics would you say a non-mapped page has? What are the LRU
routines supposed to do with such
Rik van Riel <[EMAIL PROTECTED]> writes:
> On Mon, 25 Dec 2000, Dan Aloni wrote:
> > On 25 Dec 2000, Zlatko Calusic wrote:
> >
> > > Speaking of page_launder() I just stumbled upon two oopsen today on
> > > the UP build. Maybe it could give a hint to someone, I'm not that good
> > > at Oops
On Mon, 25 Dec 2000, Dan Aloni wrote:
> On 25 Dec 2000, Zlatko Calusic wrote:
>
> > Speaking of page_launder() I just stumbled upon two oopsen today on
> > the UP build. Maybe it could give a hint to someone, I'm not that good
> > at Oops decoding.
>
> I've decoded the Oops I got, and found
> I can just imagine Xmas at the Torvalds residence, with their annual=20
> tradition of having the kids scream... But dad, other kids have the lig=
> hts=20
> strung around the trees, not the computer
I don't think you get the full picture. I suspect what gets strung up on the
trees at
> This all only matters to things that do shared writable mmap's.
>
> Almost nothing does that. innd is (sadly) the only regular thing that uses
> this, which is why it's always innd that breaks, even if everything else
> works.
btw samba 2.2 makes extensive use of shared writable mmaps (well
This all only matters to things that do shared writable mmap's.
Almost nothing does that. innd is (sadly) the only regular thing that uses
this, which is why it's always innd that breaks, even if everything else
works.
btw samba 2.2 makes extensive use of shared writable mmaps (well it
I can just imagine Xmas at the Torvalds residence, with their annual=20
tradition of having the kids scream... But dad, other kids have the lig=
hts=20
strung around the trees, not the computer
I don't think you get the full picture. I suspect what gets strung up on the
trees at
On Mon, 25 Dec 2000, Dan Aloni wrote:
On 25 Dec 2000, Zlatko Calusic wrote:
Speaking of page_launder() I just stumbled upon two oopsen today on
the UP build. Maybe it could give a hint to someone, I'm not that good
at Oops decoding.
I've decoded the Oops I got, and found that the
Rik van Riel [EMAIL PROTECTED] writes:
On Mon, 25 Dec 2000, Dan Aloni wrote:
On 25 Dec 2000, Zlatko Calusic wrote:
Speaking of page_launder() I just stumbled upon two oopsen today on
the UP build. Maybe it could give a hint to someone, I'm not that good
at Oops decoding.
I've
On Wed, 27 Dec 2000, Rik van Riel wrote:
The (trivial) patch below should fix this problem.
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What semantics would you say a non-mapped page has? What are the LRU
routines supposed to do with such a
On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What about pages with a mapping but without a writepage function ? or pages
whose writepage function fails ? The current code seems to
On Wed, 27 Dec 2000, Philipp Rumpf wrote:
On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What about pages with a mapping but without a writepage function ? or pages
whose
On Wed, 27 Dec 2000, Philipp Rumpf wrote:
On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What about pages with a mapping but without a writepage function ? or pages
whose
On Thu, 28 Dec 2000, Dan Aloni wrote:
On Wed, 27 Dec 2000, Philipp Rumpf wrote:
On Wed, Dec 27, 2000 at 03:41:04PM -0800, Linus Torvalds wrote:
It must be wrong.
If we have a dirty page on the LRU lists, that page _must_ have a mapping.
What about pages with a mapping but
On Thu, 28 Dec 2000, Chris Wedgwood wrote:
(cc' list trimmed)
[further]
I use ramfs for /tmp on my laptop -- it's very handy because it
extends the amount of the the disk had spent spun down and therefore
battery life; but writing large files into /tmp can blow away the
system or at the
> Yeah, yeah, it's 7PM Christmas Eve over there, and you're in the middle of
> your Christmas dinner. You might feel that it's unreasonable of me to ask
> you to test out my latest crazy idea.
>
> How selfish of you.
>
> Get back there in front of the computer NOW. Christmas can wait.
>
>
On Mon, 25 Dec 2000, Alan Cox wrote:
>
> > The simple fix is along the lines of adding code to fsync() that walks the
> > inode page list and writes out dirty pages.
> >
> > The clever and clean fix is to split the inode page list into two lists,
> > one for dirty and one for clean pages, and
> The simple fix is along the lines of adding code to fsync() that walks the
> inode page list and writes out dirty pages.
>
> The clever and clean fix is to split the inode page list into two lists,
> one for dirty and one for clean pages, and only walk the dirty list.
Like the patches that
The simple fix is along the lines of adding code to fsync() that walks the
inode page list and writes out dirty pages.
The clever and clean fix is to split the inode page list into two lists,
one for dirty and one for clean pages, and only walk the dirty list.
Like the patches that were
On Mon, 25 Dec 2000, Alan Cox wrote:
The simple fix is along the lines of adding code to fsync() that walks the
inode page list and writes out dirty pages.
The clever and clean fix is to split the inode page list into two lists,
one for dirty and one for clean pages, and only walk
Yeah, yeah, it's 7PM Christmas Eve over there, and you're in the middle of
your Christmas dinner. You might feel that it's unreasonable of me to ask
you to test out my latest crazy idea.
How selfish of you.
Get back there in front of the computer NOW. Christmas can wait.
On Tue, 26 Dec 2000, Chris Wedgwood wrote:
> On Mon, Dec 25, 2000 at 01:42:33AM -0800, Linus Torvalds wrote:
>
> We just don't write them out. Because right now the only thing
> that writes out dirty pages is memory pressure. "sync()",
> "fsync()" and "fdatasync()" will happily
On Mon, 25 Dec 2000, Marco d'Itri wrote:
>
> >Do you get any messages? I don't think you will, but it should be tested.
>
> I read you found the real cause so that may be bogus, but I have got two
> messages while booting. The first showed up while doing the fsck of a 6
> GB file systems and
On Dec 25, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>Add a printk() to __remove_inode_page() that complains whenever it removes
>a dirty page.
>
>Oh, in order to not see this with swap pages (which _can_ be removed when
>they are dirty, if all users of them are gone), add a
On Mon, 25 Dec 2000, Linus Torvalds wrote:
>
> Assuming we don't lose any PG_dirty bits, we might of course just lose it
> from the page tables themselves before it ever even gets to "struct page".
> I'm just surprised that it seems to be so repeatable for you - it sounds
> like we _never_
On Mon, 25 Dec 2000, Marco d'Itri wrote:
> On Dec 24, Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
> >/* The page is dirty, or locked, move to inactive_dirty list. */
> >if (page->buffers || TryLockPage(page)) {
> >...
> >
> >and change the test to
> >
> >if
On Mon, 25 Dec 2000, Marco d'Itri wrote:
On Dec 24, Linus Torvalds [EMAIL PROTECTED] wrote:
/* The page is dirty, or locked, move to inactive_dirty list. */
if (page-buffers || TryLockPage(page)) {
...
and change the test to
if (page-buffers ||
On Mon, 25 Dec 2000, Linus Torvalds wrote:
Assuming we don't lose any PG_dirty bits, we might of course just lose it
from the page tables themselves before it ever even gets to "struct page".
I'm just surprised that it seems to be so repeatable for you - it sounds
like we _never_ actually
On Dec 25, Linus Torvalds [EMAIL PROTECTED] wrote:
Add a printk() to __remove_inode_page() that complains whenever it removes
a dirty page.
Oh, in order to not see this with swap pages (which _can_ be removed when
they are dirty, if all users of them are gone), add a PageClearDirty() to
On Mon, 25 Dec 2000, Marco d'Itri wrote:
Do you get any messages? I don't think you will, but it should be tested.
I read you found the real cause so that may be bogus, but I have got two
messages while booting. The first showed up while doing the fsck of a 6
GB file systems and killed
On Tue, 26 Dec 2000, Chris Wedgwood wrote:
On Mon, Dec 25, 2000 at 01:42:33AM -0800, Linus Torvalds wrote:
We just don't write them out. Because right now the only thing
that writes out dirty pages is memory pressure. "sync()",
"fsync()" and "fdatasync()" will happily ignore
Marco d'Itri wrote:
> And I have another problem: I'm experiencing random hangs using X[1] with
> 2.4.0-test12. After a variable amount of time, some of the times I use X
> (I mostly use console) it just freezes hard (no caps lock activity).
> I'm not sure if this only happens while using X or
On 25 Dec 2000, Zlatko Calusic wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > On Sun, 24 Dec 2000, Linus Torvalds wrote:
> > >
> > > Marco, would you mind changing the test in reclaim_page(), somewheer
> > > around line mm/vmscan.c:487 that says:
> >
>
> Speaking of page_launder()
On Dec 24, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> /* The page is dirty, or locked, move to inactive_dirty list. */
> if (page->buffers || TryLockPage(page)) {
> ...
>
>and change the test to
>
> if (page->buffers || PageDirty(page) || TryLockPage(page)) {
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Sun, 24 Dec 2000, Linus Torvalds wrote:
> >
> > Marco, would you mind changing the test in reclaim_page(), somewheer
> > around line mm/vmscan.c:487 that says:
>
Speaking of page_launder() I just stumbled upon two oopsen today on
the UP build.
On Sun, 24 Dec 2000, Daniel Phillips wrote:
>
> It looks like PG_dirty is now being used only for swap_cache pages, and
> not for buffer cache and page cache pages, is that correct?
No. PG_dirty is used for all memory mapped pages - be they anonymous or
not.
These days the buffer dirty
Linus Torvalds wrote:
> Hmm.. I wonder if such a dirty page might have been moved to the
> "inactive_clean" list some way? It shouldn't really be there, as the page
> had users, but if it gets on that list we'd not have tested the dirty bit.
>
> Marco, would you mind changing the test in
>
> Get back there in front of the computer NOW. Christmas can wait.
>
> Linus "the Grinch" Torvalds
Hoo - Hoo - Hoo,
you've been very naughty Linus.
Asking people to work on Christmas evening.
My god Linus, that's so naughty that I add
it to my list...
As soon as I'm
On Sun, 24 Dec 2000, Linus Torvalds wrote:
>
> Marco, would you mind changing the test in reclaim_page(), somewheer
> around line mm/vmscan.c:487 that says:
Yeah, yeah, it's 7PM Christmas Eve over there, and you're in the middle of
your Christmas dinner. You might feel that it's unreasonable
On Sun, 24 Dec 2000, Marco d'Itri wrote:
> On Dec 24, Alexander Viro <[EMAIL PROTECTED]> wrote:
>
> >> I put "cp active active.ok" in the rc file before shutting down the
> >> daemon and at the next boot the files are different, every time.
> >
> >Could you send me both files? BTW, which
On Dec 24, Alexander Viro <[EMAIL PROTECTED]> wrote:
>> I put "cp active active.ok" in the rc file before shutting down the
>> daemon and at the next boot the files are different, every time.
>
>Could you send me both files? BTW, which filesystem it is?
I use ext2. The files are not
"Marco d'Itri" ([EMAIL PROTECTED]) wrote:
> I can confirm the bug which loses updates to the inn active file when
> it's unmapped is present again in 2.4.0-test12.
It is also still in 2.4.0-test13-pre4 in case someone thought they had
fixed it.
--
Jeff Lightfoot --jeffml at pobox.com
I can confirm the bug which loses updates to the inn active file when
it's unmapped is present again in 2.4.0-test12.
I put "cp active active.ok" in the rc file before shutting down the
daemon and at the next boot the files are different, every time.
Alexander Viro posted this test case:
I can confirm the bug which loses updates to the inn active file when
it's unmapped is present again in 2.4.0-test12.
I put "cp active active.ok" in the rc file before shutting down the
daemon and at the next boot the files are different, every time.
Alexander Viro posted this test case:
1 - 100 of 110 matches
Mail list logo
