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 share
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
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
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 seem
-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
any
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.
>
> A
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 compl
> > 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 desi
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:
> > http://innominate.org/~graichen/projects/lxr/source/mm/filemap.c?v
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
> e
[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 almos
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 (it
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 th
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 t
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 fo
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 wit
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 ha
> 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
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 th
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
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 deco
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
> 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 Chris
> 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
> 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 o
> 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 wer
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 ign
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 ki
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(
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_ actu
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
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 it
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)) {
D
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. Ma
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 bits
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 reclaim_
>
> 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 o
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 fi
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 corrupted
"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 --
55 matches
Mail list logo
