Hi Linus,
This is the second part of my patches.
Writing out of a mapping of a tmpfs file into the same file can
deadlock. This is running in the -ac series since some while.
Please apply
Christoph
diff -uNr 6-pre8-fix1/include/linux/shmem_fs.h
-pre8/mm/shmem.c 6-pre8-fix1/mm/shmem.c
--- 6-pre8/mm/shmem.c Tue Jun 12 09:49:28 2001
+++ 6-pre8-fix1/mm/shmem.c Tue Jul 3 08:55:20 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
-pre8/mm/shmem.c 6-pre8-fix1/mm/shmem.c
--- 6-pre8/mm/shmem.c Tue Jun 12 09:49:28 2001
+++ 6-pre8-fix1/mm/shmem.c Tue Jul 3 08:55:20 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
Hi Linus,
This is the second part of my patches.
Writing out of a mapping of a tmpfs file into the same file can
deadlock. This is running in the -ac series since some while.
Please apply
Christoph
diff -uNr 6-pre8-fix1/include/linux/shmem_fs.h
Hi Alan,
here is the patch you backed out for -ac22.
I slightly changed the approach: I do not rely on removepage to
calculate the fs size any more since the special-casing was ugly and
PG_marker was dropped. But I use removepage for the shmem_nrpages
calculation.
Please apply
Hi Alan,
here is the patch you backed out for -ac22.
I slightly changed the approach: I do not rely on removepage to
calculate the fs size any more since the special-casing was ugly and
PG_marker was dropped. But I use removepage for the shmem_nrpages
calculation.
Please apply
Hi Allan,
On Sun, 24 Jun 2001, Allan Duncan wrote:
> OK, it's fine by me if the "shared" under 2.2.x is not the same,
> however in that case the field should not appear at all in meminfo,
> rather than the current zero value, which leads lesser kernel
> hackers like me up the garden path.
This
Hi Allan,
On Sun, 24 Jun 2001, Allan Duncan wrote:
OK, it's fine by me if the shared under 2.2.x is not the same,
however in that case the field should not appear at all in meminfo,
rather than the current zero value, which leads lesser kernel
hackers like me up the garden path.
This would
Hi Albert,
On Sat, 23 Jun 2001, Albert D. Cahalan wrote:
> You misunderstood what 2.2.xx kernels were reporting.
> The "shared" memory in /proc/meminfo refers to something
> completely unrelated to SysV shared memory. This is no
> longer calculated because the computation was too costly.
But
Hi Albert,
On Sat, 23 Jun 2001, Albert D. Cahalan wrote:
You misunderstood what 2.2.xx kernels were reporting.
The shared memory in /proc/meminfo refers to something
completely unrelated to SysV shared memory. This is no
longer calculated because the computation was too costly.
But the load
-fix/mm/shmem.c Thu Jun 21 15:52:26 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
+ * 2000-2001 Christoph Rohland
+ * 2000-2001 SAP AG
*
* This file is released under
Hi Alan,
On Tue, 19 Jun 2001, Alan Cox wrote:
> 2.4.5-ac16
> o Drop the shmem/removepage changes to see if they(me)
> are cuaisng the instabilities in ac15
Any conclusions on that?
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe
-fix/mm/shmem.c Thu Jun 21 15:52:26 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
+ * 2000-2001 Christoph Rohland
+ * 2000-2001 SAP AG
*
* This file is released under
Hi Dieter,
On Fri, 15 Jun 2001, Dieter Nützel wrote:
> I see 4.29 GB under shm with your latest try.
> something wrong?
Yes, this is nasty. The appended patch fixes that. (I am not really
happy to need the PG_marker flag for writepage.)
The patch also fixes two other problems:
-
Hi Dieter,
On Fri, 15 Jun 2001, Dieter Nützel wrote:
I see 4.29 GB under shm with your latest try.
something wrong?
Yes, this is nasty. The appended patch fixes that. (I am not really
happy to need the PG_marker flag for writepage.)
The patch also fixes two other problems:
- shmem_file_setup
Hi Alan,
ramfs accounting does not get notified when a clean page gets dropped
from the inode.
Also tmpfs should use the new function to do accurate accounting. Else
the cached field in -ac will get spurious negative values.
The following patch fixes both.
Greetings
Christoph
Hi Pavel,
On Fri, 8 Jun 2001, Pavel Roskin wrote:
> Hello!
>
> It appears that a system with tmpfs mounted with the default (!!!)
> parameters can be used by ordinary users to make the system
> non-functional.
...
> 1) tmpfs, as opposed to ramfs doesn't limit the usage by
>default. It's
Hi Pavel,
On Fri, 8 Jun 2001, Pavel Roskin wrote:
Hello!
It appears that a system with tmpfs mounted with the default (!!!)
parameters can be used by ordinary users to make the system
non-functional.
...
1) tmpfs, as opposed to ramfs doesn't limit the usage by
default. It's not a
Hi Alan,
ramfs accounting does not get notified when a clean page gets dropped
from the inode.
Also tmpfs should use the new function to do accurate accounting. Else
the cached field in -ac will get spurious negative values.
The following patch fixes both.
Greetings
Christoph
Hi Peter,
On Tue, 12 Jun 2001, Peter Niemayer wrote:
> I just noticed that when I attach some SYSV shared memory segments
> to my process and then that process dies from a SIGSEGV that _all_
> the shared memory is dumped into the core file, even if it was never
> used and therefore didn't show
Hi Peter,
On Tue, 12 Jun 2001, Peter Niemayer wrote:
I just noticed that when I attach some SYSV shared memory segments
to my process and then that process dies from a SIGSEGV that _all_
the shared memory is dumped into the core file, even if it was never
used and therefore didn't show up in
Hi Linus,
On Mon, 21 May 2001, Linus Torvalds wrote:
> In article <[EMAIL PROTECTED]>, Christoph Rohland
> <[EMAIL PROTECTED]> wrote:
>>
>>tmpfs does not provide the necessary functions for sendfile and lo:
>>readpage, prepare_write and commitwrite.
>&g
Hi Linus,
On Mon, 21 May 2001, Linus Torvalds wrote:
In article [EMAIL PROTECTED], Christoph Rohland
[EMAIL PROTECTED] wrote:
tmpfs does not provide the necessary functions for sendfile and lo:
readpage, prepare_write and commitwrite.
And I do not see a way how to provide readpage in tmpfs
Hi Pierre,
On Mon, 21 May 2001, Pierre Etchemaite wrote:
> I just found a problem GETting a file stored in tmpfs using proftpd;
> I always get a "426 Transfer aborted. Data connection closed."
>
> That could be a bug with tmpfs and sendfile in 2.4.5-pre4 :
>
> [...]
> read(8,
Hi Pierre,
On Mon, 21 May 2001, Pierre Etchemaite wrote:
I just found a problem GETting a file stored in tmpfs using proftpd;
I always get a 426 Transfer aborted. Data connection closed.
That could be a bug with tmpfs and sendfile in 2.4.5-pre4 :
[...]
read(8,
Hi Alan,
While looking at the -ac version of ramfs I noticed that there is a
new address operation introduced which I can use to cleanup shmem.
This patch throws away some magic recalculation and makes the
accounting of shmem accurate.
It also encapsulates all accesses to the superblock_info
Hi Alan,
The ramfs accounting is broken for shared mmaps. It simply does not
recognize the pages allocated by writing into a shared mapping but
takes them into account when freed.
The attached patch should fix that.
Greetings
Christoph
--- 4-ac9/fs/ramfs/inode.c Thu May
Hi Alan,
On Thu, 17 May 2001, Alan Cox wrote:
> I think you have a major tool problem.
>
> bash-2.04$ size mm/shmem.o
>text data bss dec hex filename
>7422 572 079941f3a mm/shmem.o
> bash-2.04$ size fs/ramfs/ramfs.o
>text data
Hi Alan,
On Thu, 17 May 2001, Alan Cox wrote:
I think you have a major tool problem.
bash-2.04$ size mm/shmem.o
text data bss dec hex filename
7422 572 079941f3a mm/shmem.o
bash-2.04$ size fs/ramfs/ramfs.o
text data bss
Hi Alan,
The ramfs accounting is broken for shared mmaps. It simply does not
recognize the pages allocated by writing into a shared mapping but
takes them into account when freed.
The attached patch should fix that.
Greetings
Christoph
--- 4-ac9/fs/ramfs/inode.c Thu May
Hi Alan,
While looking at the -ac version of ramfs I noticed that there is a
new address operation introduced which I can use to cleanup shmem.
This patch throws away some magic recalculation and makes the
accounting of shmem accurate.
It also encapsulates all accesses to the superblock_info
Hi Alexander,
On Wed, 16 May 2001, Alexander Viro wrote:
> Because what I need is an absolute minimum. Heck, I don't even use
> regular files (in the full variant of patch, that is). They might
> become useful, but I can live with mkdir() and mknod().
So what about adding shmem_mknod and
Hi Linus,
On Wed, 16 May 2001, Linus Torvalds wrote:
>
> On 16 May 2001, Christoph Rohland wrote:
>>
>> cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o*
>> -rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs
>> -rw-r--r--1 cr users
Hi Linus,
On Wed, 16 May 2001, Linus Torvalds wrote:
> Looks ok, but it also feels like 2.5.x stuff to me.
>
> Also, there's the question of whether to make ramfs just built-in,
> or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs
> does the same things and you need that one for
Hi Al,
On Wed, 16 May 2001, Alexander Viro wrote:
> One point that might be better done differently - since we
> need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS
> as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource
> limits patches from -ac) we might be
Hi Al,
On Wed, 16 May 2001, Alexander Viro wrote:
One point that might be better done differently - since we
need ramfs for boot I've just made fs/Config.in declare CONFIG_RAMFS
as define_bool CONFIG_RAMFS y. If ramfs grows (e.g. gets resource
limits patches from -ac) we might be
Hi Linus,
On Wed, 16 May 2001, Linus Torvalds wrote:
Looks ok, but it also feels like 2.5.x stuff to me.
Also, there's the question of whether to make ramfs just built-in,
or make _tmpfs_ built in - ramfs is certainly simpler, but tmpfs
does the same things and you need that one for
Hi Linus,
On Wed, 16 May 2001, Linus Torvalds wrote:
On 16 May 2001, Christoph Rohland wrote:
cr:/speicher/src/u4ac9 $ ls -l mm/shmem.o*
-rw-r--r--1 cr users 154652 Mai 16 19:27 mm/shmem.o-tmpfs
-rw-r--r--1 cr users 180764 Mai 16 19:24 mm/shmem.o+tmpfs
cr
Hi Alexander,
On Wed, 16 May 2001, Alexander Viro wrote:
Because what I need is an absolute minimum. Heck, I don't even use
regular files (in the full variant of patch, that is). They might
become useful, but I can live with mkdir() and mknod().
So what about adding shmem_mknod and
Hi Martin,
Here is the patch which implements triple indirect blocks in
tmpfs.
For the rest of the word: This is needed since s390x is a 64 Bit
platform with pagesize of 4k :-(
It is on top of my other tmpfs fixes which you can find at
ftp://ftp.sap.com/pub/linuxlab/people/cr
Greetings
ry than we have. */
if (sysctl_overcommit_memory)
return 1;
free = atomic_read(_pages);
- free += atomic_read(_cache_size);
+ free += cached;
free += nr_free_pages();
free += nr_swap_pages;
diff -uNr 2.4.4-mSsu/mm/shmem.c 2.4.4
Fri May 4 21:37:34 2001
+++ 2.4.4-mSsua/mm/shmem.c Mon May 7 11:13:27 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
+ * 2000-2001 Christoph Rohland
+ * 2000-2001 SAP AG
Hi Martin,
Here is the patch which implements triple indirect blocks in
tmpfs.
For the rest of the word: This is needed since s390x is a 64 Bit
platform with pagesize of 4k :-(
It is on top of my other tmpfs fixes which you can find at
ftp://ftp.sap.com/pub/linuxlab/people/cr
Greetings
Hi Mike,
On Sat, 12 May 2001, Mike Galbraith wrote:
> Why do I not see this behavior with a heavy swap throughput test
> load? It seems decidedly odd to me that swapspace should remain
> allocated on other folks lightly loaded boxen given that my heavily
> loaded box does release swapspace
Hi Mike,
On Sat, 12 May 2001, Mike Galbraith wrote:
Why do I not see this behavior with a heavy swap throughput test
load? It seems decidedly odd to me that swapspace should remain
allocated on other folks lightly loaded boxen given that my heavily
loaded box does release swapspace quite
4.4-mSsu/mm/shmem.c Fri May 4 21:37:34 2001
+++ 2.4.4-mSsua/mm/shmem.c Mon May 7 11:13:27 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
+ * 2000-2001 Christoph Rohland
+ *
/shmem.c
--- 2.4.4-mSsu/mm/shmem.c Fri May 4 21:37:34 2001
+++ 2.4.4-mSsua/mm/shmem.c Mon May 7 11:13:27 2001
@@ -3,7 +3,8 @@
*
* Copyright (C) 2000 Linus Torvalds.
* 2000 Transmeta Corp.
- * 2000 Christoph Rohland
+ * 2000-2001 Christoph Rohland
Hi,
There is some confusion about my latest tmpfs fixes. There were three
patches which are cummulative against 2.4.4:
1) deadlock fix for write out of mmap regions. (AFAIK this is
integrated in the -ac kernels)
2) encapsulate access to shmem_inode_info
3) Do inline symlinks
I attach all
Hi,
There is some confusion about my latest tmpfs fixes. There were three
patches which are cummulative against 2.4.4:
1) deadlock fix for write out of mmap regions. (AFAIK this is
integrated in the -ac kernels)
2) encapsulate access to shmem_inode_info
3) Do inline symlinks
I attach all
Hi David,
On Tue, 24 Apr 2001, David L. Parsley wrote:
>> OK I will do that for tmpfs soon. And I will do the symlink
>> inlining with that patch.
OK, here comes the patch for the symlink inlining. It is on top of my
previous patch to encapsulate access to the private inode info.
Greetings
Hi David,
On Tue, 24 Apr 2001, David L. Parsley wrote:
OK I will do that for tmpfs soon. And I will do the symlink
inlining with that patch.
OK, here comes the patch for the symlink inlining. It is on top of my
previous patch to encapsulate access to the private inode info.
Greetings
Hi,
On 24 Apr 2001, Christoph Rohland wrote:
> Hi Al,
>
> On Tue, 24 Apr 2001, Alexander Viro wrote:
>> So yes, IMO having such patches available _is_ a good thing. And in
>> 2.5 we definitely want them in the tree. If encapsulation part gets
>> there during
Hi Jacek,
On Fri, 4 May 2001, Jacek Kopecky wrote:
> I'm not in the list, please cc your replies to me.
> After upgrading to 2.4.4 I started using tmpfs for /tmp and I
> noticed a strange behavior:
>
> dd if=/dev/zero of=blah bs=1024 count=102400
> # increased my used swap space by
Hi Jacek,
On Fri, 4 May 2001, Jacek Kopecky wrote:
I'm not in the list, please cc your replies to me.
After upgrading to 2.4.4 I started using tmpfs for /tmp and I
noticed a strange behavior:
dd if=/dev/zero of=blah bs=1024 count=102400
# increased my used swap space by approx.
Hi,
On 24 Apr 2001, Christoph Rohland wrote:
Hi Al,
On Tue, 24 Apr 2001, Alexander Viro wrote:
So yes, IMO having such patches available _is_ a good thing. And in
2.5 we definitely want them in the tree. If encapsulation part gets
there during 2.4 and separate allocation is available
Hi Stephen,
On Tue, 1 May 2001, Stephen C. Tweedie wrote:
> If the locking is for a completely different reason, then a
> different semaphore is quite appropriate. In this case you're
> trying to lock the shm internal info structures, which is quite
> different from the sort of inode locking
Hi Stephen,
On Tue, 1 May 2001, Stephen C. Tweedie wrote:
If the locking is for a completely different reason, then a
different semaphore is quite appropriate. In this case you're
trying to lock the shm internal info structures, which is quite
different from the sort of inode locking which
Hi Linus and Stephen,
tmpfs deadlocks when writing into a file from a mapping of the same
file.
The problem is the following:
- shmem_file_write may call shmem_no_page and calls
shmem_getpage_locked later,
- shmem_no_page calls shmem_getpage_locked
- shmem_getpage_locked may call
Hi Alan,
On Mon, 30 Apr 2001, Alan Cox wrote:
>> paging in just released 2.4.4, but in previuos kernel, a page that
>> was paged-out, reserves its place in swap even if it is paged-in
>> again, so once you have paged-out all your ram at least once, you
>> can't get any more memory, even if swap
Hi Alan,
On Mon, 30 Apr 2001, Alan Cox wrote:
paging in just released 2.4.4, but in previuos kernel, a page that
was paged-out, reserves its place in swap even if it is paged-in
again, so once you have paged-out all your ram at least once, you
can't get any more memory, even if swap is
Hi Linus and Stephen,
tmpfs deadlocks when writing into a file from a mapping of the same
file.
The problem is the following:
- shmem_file_write may call shmem_no_page and calls
shmem_getpage_locked later,
- shmem_no_page calls shmem_getpage_locked
- shmem_getpage_locked may call
Hi Padraig,
On Fri, 27 Apr 2001, Padraig Brady wrote:
> I don't have swap so don't need tmpfs, but could probably
> use it anyway without a backing store?
Yes, it does not need backing store.
> Anyway why was ramfs created if tmpfs existed, unless tmpfs requires
> backing store? They both
On Fri, 27 Apr 2001, [EMAIL PROTECTED] wrote:
>> > tmpfs is basically ramfs with limits.
>> >
>>
>> ... and swappable.
>>
>> -hpa
>
> Hmmm and what's shmfs? Precedessor of tmpfs?
Yes.
> I even cant remember which one I use for /tmp ;-)
You can mount tmpfs also with type "shm" for
Hi Padraig,
On Thu, 26 Apr 2001, Padraig Brady wrote:
> 2. Is tmpfs is basically swap and /tmp together in a ramdisk?
>The advantage being you need to reserve less RAM for both
>together than seperately?
tmpfs is ramfs+swap+limits. It is not using ramdisks and is not
related to them.
>
Hi Padraig,
On Thu, 26 Apr 2001, Padraig Brady wrote:
2. Is tmpfs is basically swap and /tmp together in a ramdisk?
The advantage being you need to reserve less RAM for both
together than seperately?
tmpfs is ramfs+swap+limits. It is not using ramdisks and is not
related to them.
3.
On Fri, 27 Apr 2001, [EMAIL PROTECTED] wrote:
tmpfs is basically ramfs with limits.
... and swappable.
-hpa
Hmmm and what's shmfs? Precedessor of tmpfs?
Yes.
I even cant remember which one I use for /tmp ;-)
You can mount tmpfs also with type shm for compatibility. Type shm
will
Hi Padraig,
On Fri, 27 Apr 2001, Padraig Brady wrote:
I don't have swap so don't need tmpfs, but could probably
use it anyway without a backing store?
Yes, it does not need backing store.
Anyway why was ramfs created if tmpfs existed, unless tmpfs requires
backing store? They both seem
Hi Andreas,
On Tue, 24 Apr 2001, Andreas Dilger wrote:
> On the other hand, sockets and shmem are both relatively large...
shmem is only large because the union is large. I introduced the
direct swap array of size SHMEM_NR_DIRECT simply to take advantage of
the union. We can decrease
Hi,
On Tue, 24 Apr 2001, Jakub Jelinek wrote:
> On Tue, Apr 24, 2001 at 11:46:20AM -0500, Tom Brusehaver (N-Sysdyne
> Corporation) wrote:
>>
>> I have been chasing all around trying to find out why
>> shm_open always returns ENOSYS. It is implemented
>> in glibc-2.2.2, and seems the 2.4.3
Hi,
On Tue, 24 Apr 2001, Jakub Jelinek wrote:
On Tue, Apr 24, 2001 at 11:46:20AM -0500, Tom Brusehaver (N-Sysdyne
Corporation) wrote:
I have been chasing all around trying to find out why
shm_open always returns ENOSYS. It is implemented
in glibc-2.2.2, and seems the 2.4.3 kernel knows
Hi Andreas,
On Tue, 24 Apr 2001, Andreas Dilger wrote:
On the other hand, sockets and shmem are both relatively large...
shmem is only large because the union is large. I introduced the
direct swap array of size SHMEM_NR_DIRECT simply to take advantage of
the union. We can decrease
Hi Al,
On Tue, 24 Apr 2001, Alexander Viro wrote:
> So yes, IMO having such patches available _is_ a good thing. And in
> 2.5 we definitely want them in the tree. If encapsulation part gets
> there during 2.4 and separate allocation is available for all of
> them it will be easier to do without
Hi Al,
On Tue, 24 Apr 2001, Alexander Viro wrote:
>> Half an hour? If it takes more than about 5 minutes for JFFS2 I'd
>> be very surprised.
>
> What's stopping you?
> You _are_ JFFS maintainer, aren't you?
So is this the start to change all filesystems in 2.4? I am not sure
we should do
Hi Alexander,
On Mon, 23 Apr 2001, Alexander Viro wrote:
>> I like it. ext2fs does the same, so there should be no VFS
>> hassles involved. Al?
>
> We should get ext2 and friends to move the sucker _out_ of struct
> inode. As it is, sizeof(struct inode) is way too large. This is 2.5
> stuff,
Hi Alexander,
On Mon, 23 Apr 2001, Alexander Viro wrote:
I like it. ext2fs does the same, so there should be no VFS
hassles involved. Al?
We should get ext2 and friends to move the sucker _out_ of struct
inode. As it is, sizeof(struct inode) is way too large. This is 2.5
stuff, but it
Hi Al,
On Tue, 24 Apr 2001, Alexander Viro wrote:
Half an hour? If it takes more than about 5 minutes for JFFS2 I'd
be very surprised.
tone polite What's stopping you? /tone
You _are_ JFFS maintainer, aren't you?
So is this the start to change all filesystems in 2.4? I am not sure
we
Hi Al,
On Tue, 24 Apr 2001, Alexander Viro wrote:
So yes, IMO having such patches available _is_ a good thing. And in
2.5 we definitely want them in the tree. If encapsulation part gets
there during 2.4 and separate allocation is available for all of
them it will be easier to do without PITA
Hi Ingo,
On Mon, 23 Apr 2001, Ingo Oeser wrote:
> On Mon, Apr 23, 2001 at 01:43:27PM +0200, Christoph Rohland wrote:
>> On Sun, 22 Apr 2001, David L. Parsley wrote:
>> > attach packages inside it. Since symlinks in a tmpfs filesystem
>> > cost 4k each (ouch!), I'm con
Hi David,
On Sun, 22 Apr 2001, David L. Parsley wrote:
> I'm still working on a packaging system for diskless
> (quasi-embedded) devices. The root filesystem is all tmpfs, and I
> attach packages inside it. Since symlinks in a tmpfs filesystem
> cost 4k each (ouch!), I'm considering using
Hi David,
On Sun, 22 Apr 2001, David L. Parsley wrote:
I'm still working on a packaging system for diskless
(quasi-embedded) devices. The root filesystem is all tmpfs, and I
attach packages inside it. Since symlinks in a tmpfs filesystem
cost 4k each (ouch!), I'm considering using mount
Hi Ingo,
On Mon, 23 Apr 2001, Ingo Oeser wrote:
On Mon, Apr 23, 2001 at 01:43:27PM +0200, Christoph Rohland wrote:
On Sun, 22 Apr 2001, David L. Parsley wrote:
attach packages inside it. Since symlinks in a tmpfs filesystem
cost 4k each (ouch!), I'm considering using mount --bind
Hi Stephen,
On Tue, 17 Apr 2001, Stephen C. Tweedie wrote:
> I don't see the problem. shmem_getpage_locked appears to back off
> correctly if it encounters a swap-cached page already existing if
> swapin_readahead has installed the page first, at least with the
> code in 2.4.3-ac5.
But the
Hi Stephen,
On Tue, 17 Apr 2001, Stephen C. Tweedie wrote:
I don't see the problem. shmem_getpage_locked appears to back off
correctly if it encounters a swap-cached page already existing if
swapin_readahead has installed the page first, at least with the
code in 2.4.3-ac5.
But the swap
Hi,
On Sat, 14 Apr 2001, Marcelo Tosatti wrote:
> There is a nasty race between shmem_getpage_locked() and
> swapin_readahead() with the new shmem code (introduced in 2.4.3-ac3
> and merged in the main tree in 2.4.4-pre3):
>
> shmem_getpage_locked() finds a page in the swapcache and moves it to
Hi,
On Sat, 14 Apr 2001, Marcelo Tosatti wrote:
There is a nasty race between shmem_getpage_locked() and
swapin_readahead() with the new shmem code (introduced in 2.4.3-ac3
and merged in the main tree in 2.4.4-pre3):
shmem_getpage_locked() finds a page in the swapcache and moves it to
the
Hi Miles,
On Sat, 07 Apr 2001, Miles Lane wrote:
> I have mounted:
>
> none on /var/shm type shm (rw)
Not necessary any more.
> tmpfs on /dev/shm type tmpfs (rw)
Also not necessary, but recommended for POSIX shm. BTW it will not
work with Linus' kernel. Type "shm" is supported by
Hi Miles,
On Sat, 07 Apr 2001, Miles Lane wrote:
I have mounted:
none on /var/shm type shm (rw)
Not necessary any more.
tmpfs on /dev/shm type tmpfs (rw)
Also not necessary, but recommended for POSIX shm. BTW it will not
work with Linus' kernel. Type "shm" is supported by
On Fri, 30 Mar 2001, [EMAIL PROTECTED] wrote:
> tmpfs (or shmfs or whatever name you like) is still different in
> official series (2.4.3) and in ac series. Its a kick in the ass for
> multiboot, as offcial 2.4.3 does not recognise 'tmpfs' in fstab:
>
> shmfs /dev/shmtmpfs ...
Use
On Fri, 30 Mar 2001, [EMAIL PROTECTED] wrote:
tmpfs (or shmfs or whatever name you like) is still different in
official series (2.4.3) and in ac series. Its a kick in the ass for
multiboot, as offcial 2.4.3 does not recognise 'tmpfs' in fstab:
shmfs /dev/shmtmpfs ...
Use type
Hi Alex,
On Sat, 24 Mar 2001, Alex Riesen wrote:
> just hit by tmpfs on 2.4.2-ac20
>
> mount -t tmpfs mnt
> dd if=/dev/zero mnt/tmpfile
>
> resulted in hardly slowed system and lockup,
> and not in "No space left on device", as expected.
Use mount option "size". The default is unlimited...
Hi Alex,
On Sat, 24 Mar 2001, Alex Riesen wrote:
just hit by tmpfs on 2.4.2-ac20
mount -t tmpfs mnt
dd if=/dev/zero mnt/tmpfile
resulted in hardly slowed system and lockup,
and not in "No space left on device", as expected.
Use mount option "size". The default is unlimited...
Hi Matt,
On Sun, 4 Mar 2001, Matt Domsch wrote:
> My concern is that if there continues to be a 2GB swap
> partition/file size limitation, and you can have (as currently
> #defined) 8 swap partitions, you're limited to 16GB swap, which then
> follows a max of 8GB RAM. We'd like to sell servers
Hi Matt,
On Sun, 4 Mar 2001, Matt Domsch wrote:
My concern is that if there continues to be a 2GB swap
partition/file size limitation, and you can have (as currently
#defined) 8 swap partitions, you're limited to 16GB swap, which then
follows a max of 8GB RAM. We'd like to sell servers with
Hi Linus,
On 1 Mar 2001, Linus Torvalds wrote:
> Note how do_brk() does the merging itself (see the comment "Can we
> just expand an old anonymous mapping?"), and that it's basically
> free when done that way, with no worries about locking etc. The same
> could be done fairly trivially in mmap
Hi Linus,
On 1 Mar 2001, Linus Torvalds wrote:
Note how do_brk() does the merging itself (see the comment "Can we
just expand an old anonymous mapping?"), and that it's basically
free when done that way, with no worries about locking etc. The same
could be done fairly trivially in mmap too,
Hi Alan,
here is a patch that makes the different file timestamps work on
tmpfs.
Greetings
Christoph
--- mac10/mm/shmem.c.orig Wed Feb 14 14:39:46 2001
+++ mac10/mm/shmem.cWed Feb 14 15:30:09 2001
@@ -160,6 +160,7 @@
swp_entry_t **base, **ptr, **last;
Hi Alan,
here is a patch that makes the different file timestamps work on
tmpfs.
Greetings
Christoph
--- mac10/mm/shmem.c.orig Wed Feb 14 14:39:46 2001
+++ mac10/mm/shmem.cWed Feb 14 15:30:09 2001
@@ -160,6 +160,7 @@
swp_entry_t **base, **ptr, **last;
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 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
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
1 - 100 of 380 matches
Mail list logo
