Christoph Rohland wrote:
> As of 2.4.1-pre we pin the pages by increasing the page count for
> locked segments. No special list needed.
Sure no special list is needed. But without a special list to park
those pages on they will just circulate on the active/inactive lists,
wasting CPU cycles and
Christoph Rohland wrote:
As of 2.4.1-pre we pin the pages by increasing the page count for
locked segments. No special list needed.
Sure no special list is needed. But without a special list to park
those pages on they will just circulate on the active/inactive lists,
wasting CPU cycles and
Hi Rik,
On Wed, 17 Jan 2001, Rik van Riel wrote:
> I don't even want to start thinking about how this would
> screw up the (already fragile) page aging balance...
As of 2.4.1-pre we pin the pages by increasing the page count for
locked segments. No special list needed.
Greetings
Hi Rik,
On Wed, 17 Jan 2001, Rik van Riel wrote:
I don't even want to start thinking about how this would
screw up the (already fragile) page aging balance...
As of 2.4.1-pre we pin the pages by increasing the page count for
locked segments. No special list needed.
Greetings
On Tue, 9 Jan 2001, Daniel Phillips wrote:
> Call it 'pinned'... the pinned list would have pages with use
> count = 2 or more. A page gets off the pinned list when its use
> count goes to 1 in put_page.
I don't even want to start thinking about how this would
screw up the (already fragile)
On Tue, 9 Jan 2001, Daniel Phillips wrote:
Call it 'pinned'... the pinned list would have pages with use
count = 2 or more. A page gets off the pinned list when its use
count goes to 1 in put_page.
I don't even want to start thinking about how this would
screw up the (already fragile) page
Hi Linus,
On Tue, Jan 09, 2001 at 02:59:07PM -0800, Linus Torvalds wrote:
>
> Arguably the new semantics are perfectly valid semantics on their own, but
> I'm not sure they are acceptable.
>
> In contrast, the PG_realdirty approach would give the old behaviour of
> truly locked-down shm
Hi Linus,
On Tue, Jan 09, 2001 at 02:59:07PM -0800, Linus Torvalds wrote:
Arguably the new semantics are perfectly valid semantics on their own, but
I'm not sure they are acceptable.
In contrast, the PG_realdirty approach would give the old behaviour of
truly locked-down shm segments,
Hi Linus,
Linus Torvalds <[EMAIL PROTECTED]> writes:
> I'd really like an opinion on whether this is truly legal or not? After
> all, it does change the behaviour to mean "pages are locked only if they
> have been mapped into virtual memory". Which is not what it used to mean.
>
> Arguably the
On 9 Jan 2001, Christoph Rohland wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
> >
> > Note that this would be solved very cleanly if the SHM code would use the
> > "VM_LOCKED" flag, and actually lock the pages in the VM, instead of trying
> > to lock them down for writepage().
>
>
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
> >
> > But again, how do you clear the bit? Locking is a per-vma property,
> > not per-page. I can mmap a file twice and mlock just one of the
> > mappings. If you get a munlock(), how are you to know
On 9 Jan 2001, Christoph Rohland wrote:
> Hi Stephen,
>
> On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
> > D'oh, right --- so can't you lock a segment just by bumping
> > page_count on its pages?
>
> Looks like a good idea.
>
> Oh, and my last posting was partly bogus: I can directly get
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
> >
> > It's worse: The issue we are talking about is SYSV IPC_LOCK.
>
> The issue is locked VA pages. SysV is just one of the ways in which
> it can happen: the solution has got to address both that and
> mlock()/mlockall().
No, mlock() and
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
>
> But again, how do you clear the bit? Locking is a per-vma property,
> not per-page. I can mmap a file twice and mlock just one of the
> mappings. If you get a munlock(), how are you to know how many other
> locked mappings still exist?
Note
"Stephen C. Tweedie" wrote:
> On Tue, Jan 09, 2001 at 04:45:10PM +0100, Christoph Rohland wrote:
> >
> > AFAIU mlock'ed pages would never get deactivated since the ptes do not
> > get dropped.
>
> D'oh, right --- so can't you lock a segment just by bumping page_count
> on its pages?
Putting
Hi Stephen,
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
> D'oh, right --- so can't you lock a segment just by bumping
> page_count on its pages?
Looks like a good idea.
Oh, and my last posting was partly bogus: I can directly get the pages
with page cache lookups on the file.
Greetings
Hi,
On Tue, Jan 09, 2001 at 04:45:10PM +0100, Christoph Rohland wrote:
> Hi Stephen,
>
> AFAIU mlock'ed pages would never get deactivated since the ptes do not
> get dropped.
D'oh, right --- so can't you lock a segment just by bumping page_count
on its pages?
--Stephen
-
To unsubscribe from
Hi Stephen,
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
> On Tue, Jan 09, 2001 at 03:53:55PM +0100, Christoph Rohland wrote:
>> It's worse: The issue we are talking about is SYSV IPC_LOCK.
>
> The issue is locked VA pages. SysV is just one of the ways in which
> it can happen: the solution
Hi,
On Tue, Jan 09, 2001 at 03:53:55PM +0100, Christoph Rohland wrote:
>
> On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
> > But again, how do you clear the bit? Locking is a per-vma property,
> > not per-page. I can mmap a file twice and mlock just one of the
> > mappings. If you get a
Hi Stephen,
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
> But again, how do you clear the bit? Locking is a per-vma property,
> not per-page. I can mmap a file twice and mlock just one of the
> mappings. If you get a munlock(), how are you to know how many
> other locked mappings still
Hi,
On Mon, Jan 08, 2001 at 04:30:10PM -0200, Rik van Riel wrote:
> On Mon, 8 Jan 2001, Linus Torvalds wrote:
> >
> > The only solution I see is something like a "active_immobile"
> > list, and add entries to that list whenever "writepage()"
> > returns 1 - instead of just moving them to the
Hi,
On Mon, Jan 08, 2001 at 04:30:10PM -0200, Rik van Riel wrote:
On Mon, 8 Jan 2001, Linus Torvalds wrote:
The only solution I see is something like a "active_immobile"
list, and add entries to that list whenever "writepage()"
returns 1 - instead of just moving them to the active
Hi Stephen,
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
But again, how do you clear the bit? Locking is a per-vma property,
not per-page. I can mmap a file twice and mlock just one of the
mappings. If you get a munlock(), how are you to know how many
other locked mappings still exist?
Hi,
On Tue, Jan 09, 2001 at 03:53:55PM +0100, Christoph Rohland wrote:
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
But again, how do you clear the bit? Locking is a per-vma property,
not per-page. I can mmap a file twice and mlock just one of the
mappings. If you get a munlock(),
Hi Stephen,
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
On Tue, Jan 09, 2001 at 03:53:55PM +0100, Christoph Rohland wrote:
It's worse: The issue we are talking about is SYSV IPC_LOCK.
The issue is locked VA pages. SysV is just one of the ways in which
it can happen: the solution has got
Hi,
On Tue, Jan 09, 2001 at 04:45:10PM +0100, Christoph Rohland wrote:
Hi Stephen,
AFAIU mlock'ed pages would never get deactivated since the ptes do not
get dropped.
D'oh, right --- so can't you lock a segment just by bumping page_count
on its pages?
--Stephen
-
To unsubscribe from this
Hi Stephen,
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
D'oh, right --- so can't you lock a segment just by bumping
page_count on its pages?
Looks like a good idea.
Oh, and my last posting was partly bogus: I can directly get the pages
with page cache lookups on the file.
Greetings
"Stephen C. Tweedie" wrote:
On Tue, Jan 09, 2001 at 04:45:10PM +0100, Christoph Rohland wrote:
AFAIU mlock'ed pages would never get deactivated since the ptes do not
get dropped.
D'oh, right --- so can't you lock a segment just by bumping page_count
on its pages?
Putting this together
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
But again, how do you clear the bit? Locking is a per-vma property,
not per-page. I can mmap a file twice and mlock just one of the
mappings. If you get a munlock(), how are you to know how many other
locked mappings still exist?
Note that
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
It's worse: The issue we are talking about is SYSV IPC_LOCK.
The issue is locked VA pages. SysV is just one of the ways in which
it can happen: the solution has got to address both that and
mlock()/mlockall().
No, mlock() and mlockall()
On 9 Jan 2001, Christoph Rohland wrote:
Hi Stephen,
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
D'oh, right --- so can't you lock a segment just by bumping
page_count on its pages?
Looks like a good idea.
Oh, and my last posting was partly bogus: I can directly get the pages
Linus Torvalds [EMAIL PROTECTED] writes:
On Tue, 9 Jan 2001, Stephen C. Tweedie wrote:
But again, how do you clear the bit? Locking is a per-vma property,
not per-page. I can mmap a file twice and mlock just one of the
mappings. If you get a munlock(), how are you to know how many
On 9 Jan 2001, Christoph Rohland wrote:
Linus Torvalds [EMAIL PROTECTED] writes:
Note that this would be solved very cleanly if the SHM code would use the
"VM_LOCKED" flag, and actually lock the pages in the VM, instead of trying
to lock them down for writepage().
here comes the
Hi Linus,
Linus Torvalds [EMAIL PROTECTED] writes:
I'd really like an opinion on whether this is truly legal or not? After
all, it does change the behaviour to mean "pages are locked only if they
have been mapped into virtual memory". Which is not what it used to mean.
Arguably the new
Hi Rik,
On Mon, 8 Jan 2001, Rik van Riel wrote:
> And when the bit changes again, the page can be evicted
> from memory just fine. In the mean time, the locked pages
> will also have undergone normal page aging and at unlock
> time we know whether to swap out the page or not.
>
> I agree that
On Mon, 8 Jan 2001, Linus Torvalds wrote:
> On Mon, 8 Jan 2001, Rik van Riel wrote:
> >
> > We need a check in deactivate_page() to prevent the kernel
> > from moving pages from locked shared memory segments to the
> > inactive_dirty list.
> >
> > Christoph? Linus?
>
> The only solution I see
On Mon, 8 Jan 2001, Rik van Riel wrote:
>
> We need a check in deactivate_page() to prevent the kernel
> from moving pages from locked shared memory segments to the
> inactive_dirty list.
>
> Christoph? Linus?
The only solution I see is something like a "active_immobile" list, and
add
On Mon, 8 Jan 2001, Sergey E. Volkov wrote:
> I have a problem with 2.4.0
>
> I'm testing Informix IIF-2000 database server running on dual
> Intel Pentium II - 233. When I run 'make -j30 bzImage' in the
> kernel source, my Linux box hangs without any messages.
> Informix allocate about to 50%
Hi all!
I have a problem with 2.4.0
I'm testing Informix IIF-2000 database server running on dual Intel
Pentium II - 233. When I run 'make -j30 bzImage' in the kernel source,
my
Linux box hangs without any messages. This occurs when Informix is
running. When I stoped Informix and tryed to do
Hi all!
I have a problem with 2.4.0
I'm testing Informix IIF-2000 database server running on dual Intel
Pentium II - 233. When I run 'make -j30 bzImage' in the kernel source,
my
Linux box hangs without any messages. This occurs when Informix is
running. When I stoped Informix and tryed to do
On Mon, 8 Jan 2001, Sergey E. Volkov wrote:
I have a problem with 2.4.0
I'm testing Informix IIF-2000 database server running on dual
Intel Pentium II - 233. When I run 'make -j30 bzImage' in the
kernel source, my Linux box hangs without any messages.
Informix allocate about to 50% of
On Mon, 8 Jan 2001, Rik van Riel wrote:
We need a check in deactivate_page() to prevent the kernel
from moving pages from locked shared memory segments to the
inactive_dirty list.
Christoph? Linus?
The only solution I see is something like a "active_immobile" list, and
add entries to
On Mon, 8 Jan 2001, Linus Torvalds wrote:
On Mon, 8 Jan 2001, Rik van Riel wrote:
We need a check in deactivate_page() to prevent the kernel
from moving pages from locked shared memory segments to the
inactive_dirty list.
Christoph? Linus?
The only solution I see is something
Hi Rik,
On Mon, 8 Jan 2001, Rik van Riel wrote:
And when the bit changes again, the page can be evicted
from memory just fine. In the mean time, the locked pages
will also have undergone normal page aging and at unlock
time we know whether to swap out the page or not.
I agree that this
44 matches
Mail list logo
