- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, December 14, 2000 2:38 PM
Subject: Re: [lkml]Re: VM problems still in 2.2.18
>
> I think Andrea just earned his official God
On Sat, Dec 16, 2000 at 02:49:40AM -0800, Chris Mason wrote:
> GFP_BUFFER. As far as I know that should be safe, but the change is
Yes that's ok.
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at
On Fri, 15 Dec 2000, Alan Cox wrote:
> > Yes, the same `current' context must run the down/up pair of calls and as you
> > said it is legal to rely on it on all the places it's used.
>
> I assume thats not an issue to reiserfs ?
>
I don't think so. There are two places reiserfs calls down/up
> Now we know when we can block so we can run f_ops->write ourselfs that's also
> more efficient in terms of both performance and also memory pressure during
> swap of course.
Yep
> As said reiserfs AFIK didn't need any change, so only VFS is using
> fs_down/fs_up from the point of view of reise
On Fri, Dec 15, 2000 at 06:46:32PM +, Alan Cox wrote:
> so the actual problem is either - the returning 1 when it is the wrong answer
> - or the failure to block somewhere else (where its safe) based on a kpiod
> maintained semaphore ?
The problem is not to find a safe place where to wait, th
> o don't wait I/O completion to avoid deadlocking on the i_sem
> o swap_out returns 1 and memory balancing code so thinks we did progress
> in freeing memory and goes to allocate memory from the freelist
> without waiting I/O completion
> o repeat N times the above
so the
- Original Message -
From: "Alan Cox" <[EMAIL PROTECTED]>
To: "Mark Symonds" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, December 14, 2000 1:57 AM
Subject: Re: VM problems still in 2.2.18
Hihi,
>> Box A will randomly loc
On Fri, Dec 15, 2000 at 05:57:18PM +, Alan Cox wrote:
> How hard is it to seperate losing kpiod (optimisation) from the MAP_SHARED
> changes ? I am assuming they are two seperate issues, possibly wrongly
Losing kpiod isn't an optimization ;(. Losing kpiod is the MAP_SHARED bugfix.
The probl
> The changes in semaphore semantics are necessary to fix the spurious out of
> memory with MAP_SHARED mappings and they came together with the removal of the
> always-asynchronous kpiod. While it's certainly possible to remove it I don't
> think removing the fix for MAP_SHARED stuff is a good ide
> figure out what else from this series can be put into 19pre. Believe the
> major changes left in the aa series are bigmem and lvm. I would love to see
> lvm officially in 2.2...
lvm, 4Gb support, raid 0.90... to be honest by the time that sort of stuff
would get integrated (except maybe the
On Thu, Dec 14, 2000 at 11:17:11PM +, Alan Cox wrote:
> Andrea - can we have the core VM changes you did without adopting the
> change in semaphore semantics for file system locking which will give third
> party fs maintainers headaches and doesnt match 2.4 behaviour either ?
The changes in
Alan Cox wrote:
> > slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave
> > a lot of 'trying_to_free..' errors.
> >
> > 2.2.18 + VM-global, booted with mem=32M:
> >
> > slrnpull --expire on the same spool worked fine.
>
> I think Andrea just earned his official God status ;
> > I think Andrea just earned his official God status ;)
> So, maybe his divine VM patches will make it into 2.2.19?
The question is merely 'in what form' . I wanted to keep them seperate from
the other large changes in 2.2.18 for obvious reasons.
Andrea - can we have the core VM changes you di
On 2000/12/14 Alan Cox wrote:
> > slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave
> > a lot of 'trying_to_free..' errors.
> >
> > 2.2.18 + VM-global, booted with mem=32M:
> >
> > slrnpull --expire on the same spool worked fine.
>
> I think Andrea just earned his officia
Alan Cox wrote:
> > slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave
> > a lot of 'trying_to_free..' errors.
> >
> > 2.2.18 + VM-global, booted with mem=32M:
> >
> > slrnpull --expire on the same spool worked fine.
>
> I think Andrea just earned his official God status ;)
> slrnpull --expire on a news-spool of about 600 Mb in 200,000 files gave
> a lot of 'trying_to_free..' errors.
>
> 2.2.18 + VM-global, booted with mem=32M:
>
> slrnpull --expire on the same spool worked fine.
I think Andrea just earned his official God status ;)
-
To unsubscribe from this lis
On Thu, Dec 14, 2000 at 09:57:28AM +, Alan Cox wrote:
> > bug was discovered. Ever since, I have two boxes here
> > that keep falling over. Box A will randomly lock without
> > warning and box B will die and start printing this message
> > repeatedly on the screen until I physically hit re
> bug was discovered. Ever since, I have two boxes here
> that keep falling over. Box A will randomly lock without
> warning and box B will die and start printing this message
> repeatedly on the screen until I physically hit reset:
What are these two boxes doing ?
> Is there a patch out the
Hi,
I upgraded from 2.2.14 to 2.2.16 after the security
bug was discovered. Ever since, I have two boxes here
that keep falling over. Box A will randomly lock without
warning and box B will die and start printing this message
repeatedly on the screen until I physically hit reset:
VM: do_tr
19 matches
Mail list logo
