- 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
- 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 status ;)
Just wanted to quic
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
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
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. In
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
> 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
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,
> 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
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
> 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
> 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
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
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 have
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
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
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 idea.
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
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
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, the
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 reiserfs.
> > 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
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
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
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
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 reset:
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 list:
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 ;)
So, maybe his
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 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 did
32 matches
Mail list logo
