Hi Alan,
On Mon, 12 Feb 2001, Alan Cox wrote:
>> First, I'm glad I wasn't hallucinating, and that the mail did
>> indeed get seen by someone.
>>
>> Second, instead of reverting, can't we simply move those two lines
>> up a bit:
>
> Possibly but its a minor item that doesnt really matter anyway
Hi Admin,
On Mon, 12 Feb 2001, Admin Mailing Lists wrote:
>
> I've been using the 2.2.x series successfully, latest i used was
> 2.2.19pre7. Today i upgraded to 2.4.1-ac9 and noticed that shared
> memory shows 0. I searched the list archive briefly and someone
> said the stats have been
Hi Alan,
On Mon, 12 Feb 2001, Alan Cox wrote:
First, I'm glad I wasn't hallucinating, and that the mail did
indeed get seen by someone.
Second, instead of reverting, can't we simply move those two lines
up a bit:
Possibly but its a minor item that doesnt really matter anyway so leaving
Hi Admin,
On Mon, 12 Feb 2001, Admin Mailing Lists wrote:
I've been using the 2.2.x series successfully, latest i used was
2.2.19pre7. Today i upgraded to 2.4.1-ac9 and noticed that shared
memory shows 0. I searched the list archive briefly and someone
said the stats have been broken
Hi Alan,
On Tue, 13 Feb 2001, Alan Cox wrote:
No, I do not think that it's minor. We had to bring down running
application servers to be able to start another one, because the
new one couldn't create or attach the systemwide os-monitoring
segment and thus refused to start. That's very bad
Hi Alan,
On Tue, 13 Feb 2001, Alan Cox wrote:
Yes, I understand that. But I never got any note that my fix is
broken and I still do not understand what's the concern.
Unless Im misreading the code the segment you poke at has
potentially been freed before it is written too.
Oh yes I was
Hi Alan,
The attached patch makes tmpfs behave more like other fs's. Apparently
perl expects this.
Greetings
Christoph
diff -uNr 2.4.1-ac10/mm/shmem.c 2.4.1-ac10-nlink/mm/shmem.c
--- 2.4.1-ac10/mm/shmem.c Mon Feb 12 15:01:47 2001
+++ 2.4.1-ac10-nlink/mm/shmem.c Tue Feb 13
Hi Mike,
On Thu, 8 Feb 2001, Mike Galbraith wrote:
> Hi Christoph,
>
> While testing Jens' loop-4 patch (and not being able to find
> any way to lock it up), I stumbled onto a strange behavior.
>
> I set up an interleaved swap with one swap partition, and one
> swapfile in a loopback mounted
Hi Mike,
On Thu, 8 Feb 2001, Mike Galbraith wrote:
Hi Christoph,
While testing Jens' loop-4 patch (and not being able to find
any way to lock it up), I stumbled onto a strange behavior.
I set up an interleaved swap with one swap partition, and one
swapfile in a loopback mounted reiserfs
On Tue, 6 Feb 2001, [EMAIL PROTECTED] wrote:
> Just a little question. In previous kernels and shm patches the
> /dev/shm filesytem was invisible under a 'mount' query (just managed
> like procfs or devpts).
mount does always show all mounted fses. I asume you mean df.
> Now it appears listed
Hi Paul,
On Mon, 5 Feb 2001, [EMAIL PROTECTED] wrote:
> Christoph Rohland <[EMAIL PROTECTED]>, on Sun Feb 04, 2001 [10:53:26 AM] said:
> @>Paul <[EMAIL PROTECTED]> writes:
> @>> I finally managed to coax the cursor over to mutt and quit it. Then things
> @&
Hi Paul,
On Mon, 5 Feb 2001, [EMAIL PROTECTED] wrote:
Christoph Rohland [EMAIL PROTECTED], on Sun Feb 04, 2001 [10:53:26 AM] said:
@Paul [EMAIL PROTECTED] writes:
@ I finally managed to coax the cursor over to mutt and quit it. Then things
@ were instantly fine and I could remove 'blob
On Tue, 6 Feb 2001, [EMAIL PROTECTED] wrote:
Just a little question. In previous kernels and shm patches the
/dev/shm filesytem was invisible under a 'mount' query (just managed
like procfs or devpts).
mount does always show all mounted fses. I asume you mean df.
Now it appears listed
Hi Andreas,
On Mon, 5 Feb 2001, Andreas Dilger wrote:
>> diff -uNr 2.4.1-tmpfs/mm/shmem.c 2.4.1-tmpfs-fstat/mm/shmem.c
>> --- 2.4.1-tmpfs/mm/shmem.c Sun Feb 4 16:08:57 2001
>> +++ 2.4.1-tmpfs-fstat/mm/shmem.c Sun Feb 4 16:09:50 2001
>> @@ -696,13 +696,20 @@
>> buf->f_type =
Hi Andreas,
On Mon, 5 Feb 2001, Andreas Dilger wrote:
diff -uNr 2.4.1-tmpfs/mm/shmem.c 2.4.1-tmpfs-fstat/mm/shmem.c
--- 2.4.1-tmpfs/mm/shmem.c Sun Feb 4 16:08:57 2001
+++ 2.4.1-tmpfs-fstat/mm/shmem.c Sun Feb 4 16:09:50 2001
@@ -696,13 +696,20 @@
buf-f_type = TMPFS_MAGIC;
Christoph Rohland <[EMAIL PROTECTED]> writes:
> The following patch make shmem_statfs report some sensible size
> estimates in the case that the user does not give a size limit.
>
> This should make it more error prone when used as /tmp
Oh well
Hi,
this is my second version of tmpfs against 2.4.1. It adds more
resonable reporting on statfs when there is no size limit given.
Have fun
Christoph
diff -uNr 2.4.1/Documentation/Changes 2.4.1-tmpfs-fstat/Documentation/Changes
--- 2.4.1/Documentation/Changes Tue Jan 30
Hi Alan,
The following patch make shmem_statfs report some sensible size
estimates in the case that the user does not give a size limit.
This should make it more error prone when used as /tmp
Greetings
Christoph
diff -uNr 2.4.1-tmpfs/mm/shmem.c 2.4.1-tmpfs-fstat/mm/shmem.c
---
Mike Galbraith <[EMAIL PROTECTED]> writes:
> However, tmpfs appears to cover the functionality provided by ramfs.
> Are there any uses for ramfs which can't be handled by tmpfs?
Nothing I know of.
> The only thing I could think of was "what if you don't have a
> swap device up and running".
"J . A . Magallon" <[EMAIL PROTECTED]> writes:
> There was a post recently (that now I can't find), that said the shm
> management was done with an interal fs. Was that Posix or sysv shm ?
SYSV shm and shared anonymous mappings are using a kern_mount of
shm/tmpfs. So the CONFIG_TMPFS does only
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Do you need it for POSIX shm or not... if so, I would say you do need it
> (even if it's going to take some time until POSIX shm becomes widely
> used.)
Yes, you need it. glibc 2.2 will search for a shm fs on shm_open. And
without it fails. And the
"H. Peter Anvin" [EMAIL PROTECTED] writes:
Do you need it for POSIX shm or not... if so, I would say you do need it
(even if it's going to take some time until POSIX shm becomes widely
used.)
Yes, you need it. glibc 2.2 will search for a shm fs on shm_open. And
without it fails. And the
"J . A . Magallon" [EMAIL PROTECTED] writes:
There was a post recently (that now I can't find), that said the shm
management was done with an interal fs. Was that Posix or sysv shm ?
SYSV shm and shared anonymous mappings are using a kern_mount of
shm/tmpfs. So the CONFIG_TMPFS does only make
Mike Galbraith [EMAIL PROTECTED] writes:
However, tmpfs appears to cover the functionality provided by ramfs.
Are there any uses for ramfs which can't be handled by tmpfs?
Nothing I know of.
The only thing I could think of was "what if you don't have a
swap device up and running". Seems
Hi Alan,
The following patch make shmem_statfs report some sensible size
estimates in the case that the user does not give a size limit.
This should make it more error prone when used as /tmp
Greetings
Christoph
diff -uNr 2.4.1-tmpfs/mm/shmem.c 2.4.1-tmpfs-fstat/mm/shmem.c
---
Hi,
this is my second version of tmpfs against 2.4.1. It adds more
resonable reporting on statfs when there is no size limit given.
Have fun
Christoph
diff -uNr 2.4.1/Documentation/Changes 2.4.1-tmpfs-fstat/Documentation/Changes
--- 2.4.1/Documentation/Changes Tue Jan 30
Christoph Rohland [EMAIL PROTECTED] writes:
The following patch make shmem_statfs report some sensible size
estimates in the case that the user does not give a size limit.
This should make it more error prone when used as /tmp
Oh well, Lars pointed out that I
"J . A . Magallon" <[EMAIL PROTECTED]> writes:
> I did not get the chance to deal too much with it, but apart from moving
> functionality from userspace (ipcs) to kernel (ls), what were/could be the
> benefits of /dev/shm ?. Can you create a shared memory segment by simply
> creating a file
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> > Mm, does this mean that mounting /dev/shm is no more needed ?
> > One step more towards easy 2.2 <-> 2.4 switching...
Yes, it is no longer needed. You will need for POSIX shm, but there
are not a lot of program out there using it.
> In some
"H. Peter Anvin" [EMAIL PROTECTED] writes:
Mm, does this mean that mounting /dev/shm is no more needed ?
One step more towards easy 2.2 - 2.4 switching...
Yes, it is no longer needed. You will need for POSIX shm, but there
are not a lot of program out there using it.
In some ways it's
"J . A . Magallon" [EMAIL PROTECTED] writes:
I did not get the chance to deal too much with it, but apart from moving
functionality from userspace (ipcs) to kernel (ls), what were/could be the
benefits of /dev/shm ?. Can you create a shared memory segment by simply
creating a file there, or
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> What happened with this being a management tool for shared memory
> segments?!
Unfortunately we lost this ability in the 2.4.0-test series. SYSV shm
now works only on an internal mounted instance and does not link the
directory entry to the deleted
"H. Peter Anvin" [EMAIL PROTECTED] writes:
What happened with this being a management tool for shared memory
segments?!
Unfortunately we lost this ability in the 2.4.0-test series. SYSV shm
now works only on an internal mounted instance and does not link the
directory entry to the deleted
Hi,
here is the latest version of my tmpfs patch against 2.4.1
Have fun
Christoph
diff -uNr 2.4.1/Documentation/Changes 2.4.1-tmpfs/Documentation/Changes
--- 2.4.1/Documentation/Changes Tue Jan 30 11:06:59 2001
+++ 2.4.1-tmpfs/Documentation/Changes Thu Feb 1 22:04:13 2001
@@
Hi Alan,
I decided to rename swapfs to tmpfs for administration but to call it
virtual memory fs in Documentation.
Further on the wine people asked me to export shmem_file_setup.
The attached patch does this an updates the docu.
Greetings
Christoph
diff -uNr
Hi Alan,
I decided to rename swapfs to tmpfs for administration but to call it
virtual memory fs in Documentation.
Further on the wine people asked me to export shmem_file_setup.
The attached patch does this an updates the docu.
Greetings
Christoph
diff -uNr
Hi,
here is the latest version of my tmpfs patch against 2.4.1
Have fun
Christoph
diff -uNr 2.4.1/Documentation/Changes 2.4.1-tmpfs/Documentation/Changes
--- 2.4.1/Documentation/Changes Tue Jan 30 11:06:59 2001
+++ 2.4.1-tmpfs/Documentation/Changes Thu Feb 1 22:04:13 2001
@@
Hi Linus,
On Sun, 14 Jan 2001, Linus Torvalds wrote:
> Well, as the new shm code doesn't return 1 any more, the whole
> locked page handling should just be deleted. ramfs always just
> re-marked the page dirty in its own "writepage()" function, so it
> was only shmfs that ever returned this
Hi Linus,
On Sun, 14 Jan 2001, Linus Torvalds wrote:
Well, as the new shm code doesn't return 1 any more, the whole
locked page handling should just be deleted. ramfs always just
re-marked the page dirty in its own "writepage()" function, so it
was only shmfs that ever returned this special
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
Hi Alan,
On 16 Jan 2001, Christoph Rohland wrote:
> Hi Alan,
>
> Here comes a patch for swapfs which has all my fixes against
> -ac9. It does the following:
>
> - Fix IPC_LOCK (also in 2.4.1-pre7) - Do accounting right (Also send
> to Linus) - memparse returns unsigned
Hi Alan,
Here comes a patch for swapfs which has all my fixes against -ac9. It
does the following:
- Fix IPC_LOCK (also in 2.4.1-pre7)
- Do accounting right (Also send to Linus)
- memparse returns unsigned long long (Also send to Linus)
- Fix the unresolved symbols w/o CONFIG_SWAPFS
- Introduce
On 16 Jan 2001, Christoph Rohland wrote:
> Here is a patch against 2.4.1-pre7 which
>
> 1) Adds prototype for shmem_lock to mm.h
> 2) Again brings the fixes for the accounting. I still think it
>should be applied.
And of course the prototype should be exter
Hi Linus,
Here is a patch against 2.4.1-pre7 which
1) Adds prototype for shmem_lock to mm.h
2) Again brings the fixes for the accounting. I still think it
should be applied.
Greetings
Christoph
diff -uNr 1-pre7/include/linux/mm.h m1-pre7/include/linux/mm.h
---
Hi Gregor,
On Mon, 15 Jan 2001, Gregor Jasny wrote:
> I think I've found a bug in swapfs:
>
> fstab:
> swapfs /dev/shmswapfs defaults 0 0
> swapfs /tmpswapfs defaults 0 0
>
> When I hit on a tar.gz file in Midnight Commander nothing
> happens. If I do a umonut
Hi Gregor,
On Mon, 15 Jan 2001, Gregor Jasny wrote:
I think I've found a bug in swapfs:
fstab:
swapfs /dev/shmswapfs defaults 0 0
swapfs /tmpswapfs defaults 0 0
When I hit enter on a tar.gz file in Midnight Commander nothing
happens. If I do a umonut /tmp
Hi Linus,
Here is a patch against 2.4.1-pre7 which
1) Adds prototype for shmem_lock to mm.h
2) Again brings the fixes for the accounting. I still think it
should be applied.
Greetings
Christoph
diff -uNr 1-pre7/include/linux/mm.h m1-pre7/include/linux/mm.h
---
On 16 Jan 2001, Christoph Rohland wrote:
Here is a patch against 2.4.1-pre7 which
1) Adds prototype for shmem_lock to mm.h
2) Again brings the fixes for the accounting. I still think it
should be applied.
And of course the prototype should be extern...
Greetings
Hi Alan,
Here comes a patch for swapfs which has all my fixes against -ac9. It
does the following:
- Fix IPC_LOCK (also in 2.4.1-pre7)
- Do accounting right (Also send to Linus)
- memparse returns unsigned long long (Also send to Linus)
- Fix the unresolved symbols w/o CONFIG_SWAPFS
- Introduce
Hi Alan,
On 16 Jan 2001, Christoph Rohland wrote:
Hi Alan,
Here comes a patch for swapfs which has all my fixes against
-ac9. It does the following:
- Fix IPC_LOCK (also in 2.4.1-pre7) - Do accounting right (Also send
to Linus) - memparse returns unsigned long long (Also send to Linus
Hi Randy,
On Mon, 15 Jan 2001, Randy Dunlap wrote:
> Why not (?):
Because I did not need it (always used #G or #M) and did not know the
function. But it's apparently correct to use simple_strtoull.
>> diff -uNr 2.4.0-ac/lib/cmdline.c 2.4.0-ac-memparse/lib/cmdline.c
>> ---
Hi Alan,
On 15 Jan 2001, Alan Shutko wrote:
> http://walbran.org/sean/linux/stodolsk/
>
> Haven't tried it, but it claims to work.
Works for me.
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi,
The following patch lets memparse return a long long. This is needed
to use mem= on highmem machines.
Greetings
Christoph
diff -uNr 2.4.0-ac/arch/i386/kernel/setup.c 2.4.0-ac-memparse/arch/i386/kernel/setup.c
--- 2.4.0-ac/arch/i386/kernel/setup.c Tue Jan 2 21:57:54 2001
Hi,
The following patch lets memparse return a long long. This is needed
to use mem= on highmem machines.
Greetings
Christoph
diff -uNr 2.4.0-ac/arch/i386/kernel/setup.c 2.4.0-ac-memparse/arch/i386/kernel/setup.c
--- 2.4.0-ac/arch/i386/kernel/setup.c Tue Jan 2 21:57:54 2001
Hi Alan,
On 15 Jan 2001, Alan Shutko wrote:
http://walbran.org/sean/linux/stodolsk/
Haven't tried it, but it claims to work.
Works for me.
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi Randy,
On Mon, 15 Jan 2001, Randy Dunlap wrote:
Why not (?):
Because I did not need it (always used #G or #M) and did not know the
function. But it's apparently correct to use simple_strtoull.
diff -uNr 2.4.0-ac/lib/cmdline.c 2.4.0-ac-memparse/lib/cmdline.c
--- 2.4.0-ac/lib/cmdline.c
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 14 Jan 2001, Christoph Rohland wrote:
> Why do you increment the use counter at all in nopage?
First to be able to limit the overall number of pages used by the
filesystem and second to have the right value for the number of block
Dominik Kubla <[EMAIL PROTECTED]> writes:
> Well, it's tmpfs not only on SUN but for *BSD too. So i guess we should
> follow the pack and use this name to avoid yet another "it's called this
> under that Unix and this under the other and something else under Linux"
> case.
So does *BSD also
Hi Linus,
While playing with the shmem read/write support I realised that the
accounting for shmem is broken:
Since we do not mark the page dirty at allocation time the vm can drop
it at any time as long as it is not written to. But shmem never
adjusts its accounting to that and will happily
Hi Albert,
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> Admins already know what "tmpfs" means, so you should just call
> your filesystem that. I know it isn't a pretty name, but in the
> interest of reducing confusion, you should use the existing name.
>
> Don't think of it as just "for
Steven Cole <[EMAIL PROTECTED]> writes:
> Here is a little patch which also fixes the symptoms of the build
> problem, and makes a kernel 1510 bytes smaller (without
> CONFIG_SWAPFS). Someone more knowlegable than I will have to verify
> its correctness.
Thanks, this is correct. I did not test
Steven Cole [EMAIL PROTECTED] writes:
Here is a little patch which also fixes the symptoms of the build
problem, and makes a kernel 1510 bytes smaller (without
CONFIG_SWAPFS). Someone more knowlegable than I will have to verify
its correctness.
Thanks, this is correct. I did not test the
Hi Albert,
"Albert D. Cahalan" [EMAIL PROTECTED] writes:
Admins already know what "tmpfs" means, so you should just call
your filesystem that. I know it isn't a pretty name, but in the
interest of reducing confusion, you should use the existing name.
Don't think of it as just "for /tmp".
Hi Linus,
While playing with the shmem read/write support I realised that the
accounting for shmem is broken:
Since we do not mark the page dirty at allocation time the vm can drop
it at any time as long as it is not written to. But shmem never
adjusts its accounting to that and will happily
Dominik Kubla [EMAIL PROTECTED] writes:
Well, it's tmpfs not only on SUN but for *BSD too. So i guess we should
follow the pack and use this name to avoid yet another "it's called this
under that Unix and this under the other and something else under Linux"
case.
So does *BSD also have the
Linus Torvalds [EMAIL PROTECTED] writes:
On 14 Jan 2001, Christoph Rohland wrote:
Why do you increment the use counter at all in nopage?
First to be able to limit the overall number of pages used by the
filesystem and second to have the right value for the number of blocks
in [f]stat.
Show
Hi Alan,
Here comes a patch which fixes the totally broken symlink support in
shm/swapfs. It is additional to my former patches for read and write
support.
It survives now a parallel kernel make on my 8way.
Greetings
Christoph
diff -uNr
David Ford <[EMAIL PROTECTED]> writes:
> Hmm, ok, what are the activities that use this other than shm?
You can e.g. use it for your /tmp filesystem. there seem to be some
people out there which used ramfs for that...
What do you think about "vmfs"? This probably reflects its nature
better
Hi Linus,
The shmem_symlink function is completely broken in 2.4.0 and never
worked.
This patch removes the function from 2.4.0
Greetings
Christoph
P.S.: For those which test read/write support patch: I will post patch
for my swapfs soon which will make it working on top
David Ford <[EMAIL PROTECTED]> writes:
> Now...is this shared memory or swap? If it's swap, why is it
> different than a swapfile? If you are intending the shmem be called
> swapfs, I personally thing that it'll cause a significant amount of
> confusion.
It is a filesystem which lives in RAM
Hi Alan,
Here is a patch which makes the shm fs a full swappable file system
like Solaris' tmpfs.
Does anybody have a really good fs check tool? Not benchmarking, but
concurrent truncate, read, write, unlink stress test. Would be good to
test it with that. I did my usual POSIX/SYSV shm tests
Hi,
The appended patch (additional to my read/write support patch) makes
the shm filesystem configurable and renames it to the more sensible
name swapfs. Since the fs type "shm" is quite established with 2.4 I
register that name also.
It also updates the documentation.
Greetings
Hi,
The appended patch (additional to my read/write support patch) makes
the shm filesystem configurable and renames it to the more sensible
name swapfs. Since the fs type "shm" is quite established with 2.4 I
register that name also.
It also updates the documentation.
Greetings
Hi Alan,
Here is a patch which makes the shm fs a full swappable file system
like Solaris' tmpfs.
Does anybody have a really good fs check tool? Not benchmarking, but
concurrent truncate, read, write, unlink stress test. Would be good to
test it with that. I did my usual POSIX/SYSV shm tests
David Ford [EMAIL PROTECTED] writes:
Now...is this shared memory or swap? If it's swap, why is it
different than a swapfile? If you are intending the shmem be called
swapfs, I personally thing that it'll cause a significant amount of
confusion.
It is a filesystem which lives in RAM and
Hi Linus,
The shmem_symlink function is completely broken in 2.4.0 and never
worked.
This patch removes the function from 2.4.0
Greetings
Christoph
P.S.: For those which test read/write support patch: I will post patch
for my swapfs soon which will make it working on top
David Ford [EMAIL PROTECTED] writes:
Hmm, ok, what are the activities that use this other than shm?
You can e.g. use it for your /tmp filesystem. there seem to be some
people out there which used ramfs for that...
What do you think about "vmfs"? This probably reflects its nature
better than
Hi Alan,
Here comes a patch which fixes the totally broken symlink support in
shm/swapfs. It is additional to my former patches for read and write
support.
It survives now a parallel kernel make on my 8way.
Greetings
Christoph
diff -uNr
On Fri, 12 Jan 2001, [EMAIL PROTECTED] wrote:
> Same cam be applied to shm ? Thus kernel Documentation/Changes
> should be changed:
[...]
>
> none/dev/shmshm defaults0 0
>
> to
>
> shm/dev/shmshm defaults0 0
>
Yes, I thought that I changed that :-( I
On Fri, 12 Jan 2001, [EMAIL PROTECTED] wrote:
Same cam be applied to shm ? Thus kernel Documentation/Changes
should be changed:
[...]
none/dev/shmshm defaults0 0
to
shm/dev/shmshm defaults0 0
Yes, I thought that I changed that :-( I always
Hi Alan,
The appended patch speeds up the truncate logic of shmem.c
considerably and makes it more readable.
Would you apply it to your -ac series?
I will go on with some cache lookup optimizations and probably
read/write support.
Greetings
Christoph
diff -uNr
Hi Alan,
The appended patch speeds up the truncate logic of shmem.c
considerably and makes it more readable.
Would you apply it to your -ac series?
I will go on with some cache lookup optimizations and probably
read/write support.
Greetings
Christoph
diff -uNr
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
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
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 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 ha
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 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 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 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
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
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
Hi Alan,
On Mon, 8 Jan 2001, Alan Cox wrote:
> I have been thinking about this. I think we should merge the size
> limiting code with the example clean ramfs code. Having spent a
> while debugging the LFS checks and some other funnies I realised one
> problem with the ramfs in 2.4.0 as an
Hi Christoph,
On Mon, 8 Jan 2001, Christoph Hellwig wrote:
> I had a prototype tmpfs in -test10 (ro so) times. It based on ramfs
> for all the metadata stuff and used the (old) shmfs code for
> swap-backed data. The only real problem the code had, was that it
> needed a ->allocpage
Hi Linus,
On Sun, 7 Jan 2001, Linus Torvalds wrote:
> I wonder what to do about this - the limits are obviously useful, as
> would the "use swap-space as a backing store" thing be. At the same
> time I'd really hate to lose the lean-mean-clean ramfs.
Let me repeat on this issue: shmem.c has
Hi Linus,
On Sun, 7 Jan 2001, Linus Torvalds wrote:
I wonder what to do about this - the limits are obviously useful, as
would the "use swap-space as a backing store" thing be. At the same
time I'd really hate to lose the lean-mean-clean ramfs.
Let me repeat on this issue: shmem.c has
Hi Christoph,
On Mon, 8 Jan 2001, Christoph Hellwig wrote:
I had a prototype tmpfs in -test10 (ro so) times. It based on ramfs
for all the metadata stuff and used the (old) shmfs code for
swap-backed data. The only real problem the code had, was that it
needed a -allocpage address_space
Hi Alan,
On Mon, 8 Jan 2001, Alan Cox wrote:
I have been thinking about this. I think we should merge the size
limiting code with the example clean ramfs code. Having spent a
while debugging the LFS checks and some other funnies I realised one
problem with the ramfs in 2.4.0 as an example.
101 - 200 of 380 matches
Mail list logo
