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
Matan Ziv-Av <[EMAIL PROTECTED]> writes:
> I hope it is reasonable to ask, how?
>
> What I need is to allocate a big amount of memory (say 1MB, for
> example), copy the video memory to it, and then have fixed 64K of
> virutal address of the process point to any 64K window of the large
>
Matan Ziv-Av [EMAIL PROTECTED] writes:
I hope it is reasonable to ask, how?
What I need is to allocate a big amount of memory (say 1MB, for
example), copy the video memory to it, and then have fixed 64K of
virutal address of the process point to any 64K window of the large
allocated
Chris Mason <[EMAIL PROTECTED]> writes:
> Yes, right now the shmem writepage calls are the only ones returning one at
> all. But, the question of how to properly fsync/msync these kinds of pages
> still stands. Returning from an fsync before writing them isn't correct.
Yes, and [fm]sync
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> >> [spstarr@coredump /etc]$ free
> >> total used free sharedbuffers
> ...
> >> the shmfs is mounted. Is there any configuration i need to get
> >> shm memory activiated?
> >
> > The 'shared' field in /proc/meminfo
Chris Mason <[EMAIL PROTECTED]> writes:
> Just noticed the filemap_fdatasync code doesn't check the return value from
> writepage. Linus, would you take a patch that redirtied the page, puts it
> back onto the dirty list (at the tail), and unlocks the page when writepage
> returns 1?
>
> That
Chris Mason [EMAIL PROTECTED] writes:
Just noticed the filemap_fdatasync code doesn't check the return value from
writepage. Linus, would you take a patch that redirtied the page, puts it
back onto the dirty list (at the tail), and unlocks the page when writepage
returns 1?
That would
"Albert D. Cahalan" [EMAIL PROTECTED] writes:
[spstarr@coredump /etc]$ free
total used free sharedbuffers
...
the shmfs is mounted. Is there any configuration i need to get
shm memory activiated?
The 'shared' field in /proc/meminfo (source for 'top'
Chris Mason [EMAIL PROTECTED] writes:
Yes, right now the shmem writepage calls are the only ones returning one at
all. But, the question of how to properly fsync/msync these kinds of pages
still stands. Returning from an fsync before writing them isn't correct.
Yes, and [fm]sync should not
Craig Schlenter <[EMAIL PROTECTED]> writes:
> [snip, vmstat stuff, me]
> > There is a perl program running (80 Meg's in size, 20 Megs
> > resident) that is chatting to a database and building up a large
> > hash in memory. The machine has 64M of RAM. The bit that doesn't
> > make sense is why
Craig Schlenter [EMAIL PROTECTED] writes:
[snip, vmstat stuff, me]
There is a perl program running (80 Meg's in size, 20 Megs
resident) that is chatting to a database and building up a large
hash in memory. The machine has 64M of RAM. The bit that doesn't
make sense is why the cache is
Gregory McLean <[EMAIL PROTECTED]> writes:
> cat /proc/sys/kernel/shmall
> 0
That's your problem. Your limit for overall shm pages is zero. So you
cannot allocate any shm segments.
echo 200 > /proc/sys/kernel/shmall
and check /etc/sysctl.conf or wherever your system stores kernel
Gregory McLean [EMAIL PROTECTED] writes:
cat /proc/sys/kernel/shmall
0
That's your problem. Your limit for overall shm pages is zero. So you
cannot allocate any shm segments.
echo 200 /proc/sys/kernel/shmall
and check /etc/sysctl.conf or wherever your system stores kernel
parameters to
Chris Wedgwood <[EMAIL PROTECTED]> writes:
> I would prefer we leave ramfs alone as is -- it makes an excellent
> starting point for a new fs and is fairly simple to grok. If we are
> to add any more complexity here like the size limiting patches or the
> use of a backing store, I'd like to have
Chris Wedgwood [EMAIL PROTECTED] writes:
I would prefer we leave ramfs alone as is -- it makes an excellent
starting point for a new fs and is fairly simple to grok. If we are
to add any more complexity here like the size limiting patches or the
use of a backing store, I'd like to have this
Alan Cox <[EMAIL PROTECTED]> writes:
> There are fundmental things shm* can do that mmap cannot. Does posix
> shm handle those (leaving segments alive but unattached being the
> obvious one)
Yes:
shmget == shm_open (+ ftruncate(fd, size))
shmat== mmap (0,
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 28 Dec 2000, Christoph Rohland wrote:
> >
> > First we need the following patch since otherwise we use a swap entry
> > without having the count increased:
>
> No, that shouldn't be needed.
>
> Look at
Andries Brouwer <[EMAIL PROTECTED]> writes:
> On Wed, Dec 27, 2000 at 01:16:44PM -0200, Marcelo Tosatti wrote:
> I happen to see this post, but have not followed earlier discussion.
> See a patch fragment
(The patch does not show a lot of context. You should look at the
whole files)
>
>
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 27 Dec 2000, Christoph Rohland wrote:
> Woul dyou mind testing this alternate fix instead:
Does not work, but is the right direction I think.
First we need the following patch since otherwise we use a swap entry
without having the cou
Andries Brouwer [EMAIL PROTECTED] writes:
On Wed, Dec 27, 2000 at 01:16:44PM -0200, Marcelo Tosatti wrote:
I happen to see this post, but have not followed earlier discussion.
See a patch fragment
(The patch does not show a lot of context. You should look at the
whole files)
Linus Torvalds [EMAIL PROTECTED] writes:
On 27 Dec 2000, Christoph Rohland wrote:
Woul dyou mind testing this alternate fix instead:
Does not work, but is the right direction I think.
First we need the following patch since otherwise we use a swap entry
without having the count increased
Linus Torvalds [EMAIL PROTECTED] writes:
On 28 Dec 2000, Christoph Rohland wrote:
First we need the following patch since otherwise we use a swap entry
without having the count increased:
No, that shouldn't be needed.
Look at the code-path: the kernel has the page locked, so
Alan Cox [EMAIL PROTECTED] writes:
There are fundmental things shm* can do that mmap cannot. Does posix
shm handle those (leaving segments alive but unattached being the
obvious one)
Yes:
shmget == shm_open (+ ftruncate(fd, size))
shmat== mmap (0, size,
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> I think that incrementing the swap entry count will not allow swap from
> removing the swap entry (as the comment says)
I think the culprit is somewhere else. The error occurs in nopage of a
process, not in swapoff.
Looking at the following in
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> On 27 Dec 2000, Christoph Rohland wrote:
> > The following patchlet bring the handling of shmget with size zero
> > back to the 2.2 behaviour. There seem to be programs out, which
> > (erroneously) rely on this.
>
Dave Gilbert <[EMAIL PROTECTED]> writes:
> I think I've come to the conclusion that Xine does not in the case
> I've found, rely on this - it is a separate bug related to Xv
> telling xine that it needs 0 bytes.
Yes, but this bug did not show on 2.2. It simply failed in shmget.
Probably it
Hi Linus,
The following patch (against clean test13-pre4) removes the races in
shmem_unuse. I changed inode.c to not lock the inode if there is no
write_inode function. So I can grab the inode while holding the
spinlock.
It also optimises the shmem_ftruncate behaviour.
BTW: The generic swapoff
Hi Linus,
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
Greetings
Christoph
diff -uNr c/include/linux/shm.h c1/include/linux/shm.h
--- c/include/linux/shm.h
Hi Linus,
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
Greetings
Christoph
diff -uNr c/include/linux/shm.h c1/include/linux/shm.h
--- c/include/linux/shm.h
Hi Linus,
The following patch (against clean test13-pre4) removes the races in
shmem_unuse. I changed inode.c to not lock the inode if there is no
write_inode function. So I can grab the inode while holding the
spinlock.
It also optimises the shmem_ftruncate behaviour.
BTW: The generic swapoff
Dave Gilbert [EMAIL PROTECTED] writes:
I think I've come to the conclusion that Xine does not in the case
I've found, rely on this - it is a separate bug related to Xv
telling xine that it needs 0 bytes.
Yes, but this bug did not show on 2.2. It simply failed in shmget.
Probably it makes
Marcelo Tosatti [EMAIL PROTECTED] writes:
On 27 Dec 2000, Christoph Rohland wrote:
The following patchlet bring the handling of shmget with size zero
back to the 2.2 behaviour. There seem to be programs out, which
(erroneously) rely on this.
Just curiosity: do you know if any
Marcelo Tosatti [EMAIL PROTECTED] writes:
I think that incrementing the swap entry count will not allow swap from
removing the swap entry (as the comment says)
I think the culprit is somewhere else. The error occurs in nopage of a
process, not in swapoff.
Looking at the following in
Dave Gilbert <[EMAIL PROTECTED]> writes:
> I'm trying to debug a weird problem with Xine - its screwing up its use
> of shared memory for regions I haven't sussed yet. One odd consequence is
> that it has apparently successfully managed to allocate a 0 byte chunk of
> shared memory; shmat is
Dave Gilbert [EMAIL PROTECTED] writes:
I'm trying to debug a weird problem with Xine - its screwing up its use
of shared memory for regions I haven't sussed yet. One odd consequence is
that it has apparently successfully managed to allocate a 0 byte chunk of
shared memory; shmat is then
Marcelo Tosatti <[EMAIL PROTECTED]> writes:
> Christoph is already looking at it and should have a fix soon.
Here it comes against 13-pre4 ...
We cannot call delete_from_swap_cache, it was called already in
try_to_unuse.
There is still a race when we page in the page which is
just freed in
Marcelo Tosatti [EMAIL PROTECTED] writes:
Christoph is already looking at it and should have a fix soon.
Here it comes against 13-pre4 ...
We cannot call delete_from_swap_cache, it was called already in
try_to_unuse.
There is still a race when we page in the page which is
just freed in
Hi Kevin,
On 19 Dec 2000, Kevin Buhr wrote:
> The code in Enlightenment did a complete
> shmget/shmat/shmctl(RMID)/shmdt cycle, so that segment *was* being
> constantly deleted. The Mozilla ones stuck around. The particular
> address that was being reference in the shm_nopage_core call
>
Hi Alan,
Here is a backport of the sparse core writing for 2.2. It never made
any problems on 2.[34] and makes live much easier for us.
Could you apply this to 2.2.19?
Greetings
Christoph
diff -uNr 2.2.18/fs/binfmt_elf.c c/fs/binfmt_elf.c
--- 2.2.18/fs/binfmt_elf.c Mon
Hi Alan,
here is a patch against 2.2.18 to resemble the same behaviour for
2.2 as we have in 2.4. This is what everybody else does and the 2.2
behaviour leads to some really bad situations.
Greetings
Christoph
diff -uNr 2.2.18/ipc/shm.c c/ipc/shm.c
--- 2.2.18/ipc/shm.cWed
Hi Kevin,
On 26 Nov 2000, Kevin Buhr wrote:
> The fact that this has crashed once in all the time I've been using
> this setup would seem to imply a very subtle race condition. Ugh.
I am just running a stress test on 2.4.0-test13-pre3 + appended patch
without problems. Is the shm segment
Hi Kevin,
On 26 Nov 2000, Kevin Buhr wrote:
The fact that this has crashed once in all the time I've been using
this setup would seem to imply a very subtle race condition. Ugh.
I am just running a stress test on 2.4.0-test13-pre3 + appended patch
without problems. Is the shm segment deleted
Hi Alan,
here is a patch against 2.2.18 to resemble the same behaviour for
2.2 as we have in 2.4. This is what everybody else does and the 2.2
behaviour leads to some really bad situations.
Greetings
Christoph
diff -uNr 2.2.18/ipc/shm.c c/ipc/shm.c
--- 2.2.18/ipc/shm.cWed
Hi Alan,
Here is a backport of the sparse core writing for 2.2. It never made
any problems on 2.[34] and makes live much easier for us.
Could you apply this to 2.2.19?
Greetings
Christoph
diff -uNr 2.2.18/fs/binfmt_elf.c c/fs/binfmt_elf.c
--- 2.2.18/fs/binfmt_elf.c Mon
Hi Kevin,
On 19 Dec 2000, Kevin Buhr wrote:
The code in Enlightenment did a complete
shmget/shmat/shmctl(RMID)/shmdt cycle, so that segment *was* being
constantly deleted. The Mozilla ones stuck around. The particular
address that was being reference in the shm_nopage_core call
Hi Linus,
On 18 Dec 2000, Christoph Rohland wrote:
> The appended patch fixes the following:
>
> 1) We cannot unlock the page in shmem_writepage on ooswap since
>page_launder will do this later.
>
> 2) We should set the inode number of SYSV segments to the
Hi Roderich,
On Fri, 08 Dec 2000, Roderich Schupp wrote:
>> And I'll ask again... If this is now the recommend mount point,
>> can we have devfs create this directory for us?
>
> C'mon guys, this is just to easy:
Included in 2.4.0-test13-pre3...
Greetings
Christoph
-
To
Hi Rolf,
On Wed, 8 Nov 2000, Rolf Fokkens wrote:
>> Recently we installed extra memory in our Oracle-on-Linux database
>> server, it now has 1.25 GB. I installed a 2.2.17 kernel with the
>> 2GB option enabled. I rebooted the machine (a Compaq Proliant 5500
>> dual PII 450MHz) and noticed that
Hi Janne,
On 21 Nov 2000, Janne Himanka wrote:
> I have compiled 2.4.0-test10 and 2.4.0-test11 kernels, mounted
> /dev/shm and tried to install the Perl IPC::Shareable module. "make
> test" produces a lot of errors (sample below), and a message from
> the kernel appears in /var/log/messages. I
Hi Linus,
On Sun, 17 Dec 2000, Linus Torvalds wrote:
> The shmfs cleanup should be unnoticeable except to users who use SAP
> with huge shared memory segments, where Christoph Rohlands work not
> only makes the code much more readable, it should also make it
> dependable..
:-)
The appended
Hi Linus,
On Sun, 17 Dec 2000, Linus Torvalds wrote:
The shmfs cleanup should be unnoticeable except to users who use SAP
with huge shared memory segments, where Christoph Rohlands work not
only makes the code much more readable, it should also make it
dependable..
:-)
The appended patch
Hi Janne,
On 21 Nov 2000, Janne Himanka wrote:
I have compiled 2.4.0-test10 and 2.4.0-test11 kernels, mounted
/dev/shm and tried to install the Perl IPC::Shareable module. "make
test" produces a lot of errors (sample below), and a message from
the kernel appears in /var/log/messages. I am
Hi Roderich,
On Fri, 08 Dec 2000, Roderich Schupp wrote:
And I'll ask again... If this is now the recommend mount point,
can we have devfs create this directory for us?
C'mon guys, this is just to easy:
Included in 2.4.0-test13-pre3...
Greetings
Christoph
-
To
Hi Rolf,
On Wed, 8 Nov 2000, Rolf Fokkens wrote:
Recently we installed extra memory in our Oracle-on-Linux database
server, it now has 1.25 GB. I installed a 2.2.17 kernel with the
2GB option enabled. I rebooted the machine (a Compaq Proliant 5500
dual PII 450MHz) and noticed that one of the
Hi Linus,
On 18 Dec 2000, Christoph Rohland wrote:
The appended patch fixes the following:
1) We cannot unlock the page in shmem_writepage on ooswap since
page_launder will do this later.
2) We should set the inode number of SYSV segments to the (user)
shmid and not the internal
Linus Torvalds <[EMAIL PROTECTED]> writes:
> The only comment I have is that as far as I can tell, your shm_writepage()
> has a small bug: if "__get_swap_page()" fails, we can't just drop the
> dirty page in question, so instead of returning -ENOMEM we should really
> return a "1" to tell the VM
cSun Dec 17 12:54:02 2000
+++ c/ipc/shm.c Sun Dec 17 16:10:06 2000
@@ -9,23 +9,10 @@
* BIGMEM support, Andrea Arcangeli <[EMAIL PROTECTED]>
* SMP thread shm, Jean-Luc Boyard <[EMAIL PROTECTED]>
* HIGHMEM support, Ingo Molnar <[EMAIL PROTECTED]>
- * avoid vmalloc and mak
EM support, Ingo Molnar [EMAIL PROTECTED]
- * avoid vmalloc and make shmmax, shmall, shmmni sysctl'able,
- * Christoph Rohland [EMAIL PROTECTED]
+ * Make shmmax, shmall, shmmni sysctl'able, Christoph Rohland [EMAIL PROTECTED]
* Shared /dev/zero support, Kanoj Sarcar [EMAIL PROTECTE
Linus Torvalds [EMAIL PROTECTED] writes:
The only comment I have is that as far as I can tell, your shm_writepage()
has a small bug: if "__get_swap_page()" fails, we can't just drop the
dirty page in question, so instead of returning -ENOMEM we should really
return a "1" to tell the VM to
D]>
* SMP thread shm, Jean-Luc Boyard <[EMAIL PROTECTED]>
* HIGHMEM support, Ingo Molnar <[EMAIL PROTECTED]>
- * avoid vmalloc and make shmmax, shmall, shmmni sysctl'able,
- * Christoph Rohland <[EMAIL PROTECTED]>
* Shared /dev/zero support, Kano
Hi David,
On Wed, 13 Dec 2000, David Howells wrote:
> Looks interesting.
>
> There looks to be a logical mapping between CreateFileMapping() +
> MEM_SHARED and your shmem_file_setup(), as long as anonymously named
> sections are catered for (not difficult).
Yup.
> There also looks to be a
Hi David,
On Wed, 13 Dec 2000, David Howells wrote:
>>> I'm currently writing a Win32 emulation kernel module to help
>>> speed Wine up,
>^
>> fd = shm_open ("xxx",...)
>> ptr = mmap (NULL, size, ..., fd, offset);
>
> I am doing this from
Hi David,
On Wed, 13 Dec 2000, David Howells wrote:
I'm currently writing a Win32 emulation kernel module to help
speed Wine up,
^
fd = shm_open ("xxx",...)
ptr = mmap (NULL, size, ..., fd, offset);
I am doing this from within kernel
Hi David,
On Wed, 13 Dec 2000, David Howells wrote:
Looks interesting.
There looks to be a logical mapping between CreateFileMapping() +
MEM_SHARED and your shmem_file_setup(), as long as anonymously named
sections are catered for (not difficult).
Yup.
There also looks to be a logical
000
@@ -9,23 +9,10 @@
* BIGMEM support, Andrea Arcangeli [EMAIL PROTECTED]
* SMP thread shm, Jean-Luc Boyard [EMAIL PROTECTED]
* HIGHMEM support, Ingo Molnar [EMAIL PROTECTED]
- * avoid vmalloc and make shmmax, shmall, shmmni sysctl'able,
- * Christoph Rohland [EMAIL
"David D.W. Downey" <[EMAIL PROTECTED]> writes:
> When running top, procinfo, or free I get 0 for Shared memory. Obviously
> this is incorrect. What has changed from the 2.2.x and the 2.4.x that
> would cause these apps to misreport this information.
Known 2.4 behaviour. It is simply to costly
Hi Linus,
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 8 Dec 2000, Christoph Rohland wrote:
> >
> > here is my first shot for cleaning up the shm handling. It did
> > survive some basic testing but is not ready for inclusion.
>
> The only comment I have righ
David Howells <[EMAIL PROTECTED]> writes:
> Can you help me with an SHM related problem?
>
> I'm currently writing a Win32 emulation kernel module to help speed Wine up,
> and I'm writing the file mapping support stuff at the moment
> (CreateFileMapping and MapViewOfFile).
These two calls were
c/shm.cTue Dec 5 08:35:08 2000
+++ c/ipc/shm.c Fri Dec 8 11:30:48 2000
@@ -9,23 +9,10 @@
* BIGMEM support, Andrea Arcangeli <[EMAIL PROTECTED]>
* SMP thread shm, Jean-Luc Boyard <[EMAIL PROTECTED]>
* HIGHMEM support, Ingo Molnar <[EMAIL PROTECTED]>
- * avoid vmalloc and
Luc Boyard [EMAIL PROTECTED]
* HIGHMEM support, Ingo Molnar [EMAIL PROTECTED]
- * avoid vmalloc and make shmmax, shmall, shmmni sysctl'able,
- * Christoph Rohland [EMAIL PROTECTED]
* Shared /dev/zero support, Kanoj Sarcar [EMAIL PROTECTED]
- * make it a file system, Chri
David Howells [EMAIL PROTECTED] writes:
Can you help me with an SHM related problem?
I'm currently writing a Win32 emulation kernel module to help speed Wine up,
and I'm writing the file mapping support stuff at the moment
(CreateFileMapping and MapViewOfFile).
These two calls were
Hi Linus,
Linus Torvalds [EMAIL PROTECTED] writes:
On 8 Dec 2000, Christoph Rohland wrote:
here is my first shot for cleaning up the shm handling. It did
survive some basic testing but is not ready for inclusion.
The only comment I have right now is that you probably should not
mark
Hi Kevin,
[EMAIL PROTECTED] (Kevin Buhr) writes:
> I know no way to reproduce it. I've been using "test5" reliably since
> just after its release, and I've triggered this bug only the one time.
That's what I feared :-(
> I use a SysReq patch to do an oops-style dump instead of the usual
>
Hi Kevin,
[EMAIL PROTECTED] (Kevin Buhr) writes:
I know no way to reproduce it. I've been using "test5" reliably since
just after its release, and I've triggered this bug only the one time.
That's what I feared :-(
I use a SysReq patch to do an oops-style dump instead of the usual
Hi Kevin,
[EMAIL PROTECTED] (Kevin Buhr) writes:
> The SHM locking has thwarted my attempts at understanding. Maybe
> someone else can see the bug or reassure me that it's already been
> fixed in test11?
This is the first report of such corruption. If it's real it is _not_
fixed between test5
Hi Kevin,
[EMAIL PROTECTED] (Kevin Buhr) writes:
The SHM locking has thwarted my attempts at understanding. Maybe
someone else can see the bug or reassure me that it's already been
fixed in test11?
This is the first report of such corruption. If it's real it is _not_
fixed between test5 and
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Fri, Nov 17, 2000 at 05:06:49PM +0100, Christoph Rohland wrote:
> > Could I get this for i686? :-)
>
> If we break binary compatibility yes.
OK, I'll stick to rdtsc on ix86
Christoph
-
To unsubscribe from thi
Hi David,
David Mansfield <[EMAIL PROTECTED]> writes:
> If you can find the time to check this out more completely, I recommend
> it, because it seems like a great improvement to be able to accurately
> see vmstat numbers in times of system load. I hope the other side
> effects are beneficial
Hi David,
David Mansfield [EMAIL PROTECTED] writes:
If you can find the time to check this out more completely, I recommend
it, because it seems like a great improvement to be able to accurately
see vmstat numbers in times of system load. I hope the other side
effects are beneficial as well
Andrea Arcangeli [EMAIL PROTECTED] writes:
On Fri, Nov 17, 2000 at 05:06:49PM +0100, Christoph Rohland wrote:
Could I get this for i686? :-)
If we break binary compatibility yes.
OK, I'll stick to rdtsc on ix86
Christoph
-
To unsubscribe from this list: send the line
On Fri, 17 Nov 2000, [EMAIL PROTECTED] wrote:
> If I rememeber correctly there where some problems with
> SHM handling still left to resolve...
Nope.
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi Andrea,
On Fri, 17 Nov 2000, Andrea Arcangeli wrote:
> So as worse you'll have to wait x86-64 to get that lightweight
> vgettimeofday.
Could I get this for i686? :-)
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
Hi Tigran,
On Fri, 17 Nov 2000, Tigran Aivazian wrote:
> On Fri, 17 Nov 2000, Andi Kleen wrote:
>> [of course rdtsc only works properly on UP or with bind_cpu()]
>
> I thought Linux kernel does synchronize them on boot? So, you are
> saying I cannot rely on this being 100% correct?
Yes, it
Hi Jeff,
On Fri, 17 Nov 2000, Jeff Garzik wrote:
> IIRC, this came up a long time ago WRT Apache, which made a lot of
> gettimeofday() calls. Someone (Linus?) proposed the solution of a
> 'magic page' which holds information like gettimeofday() stuff, but
> could be handled much more rapidly
Hi Alan,
On Fri, 17 Nov 2000, Alan Cox wrote:
> Even checking the cpuinfo for the TSC should be done with care, and
> its far far better to use gettimeofday unless doing very tiny
> timings (eg for optimising code paths)
gettimeofday is _way_ to slow for a lot of every day uses. So
applications
Hi Alan,
On Fri, 17 Nov 2000, Alan Cox wrote:
Even checking the cpuinfo for the TSC should be done with care, and
its far far better to use gettimeofday unless doing very tiny
timings (eg for optimising code paths)
gettimeofday is _way_ to slow for a lot of every day uses. So
applications
Hi Jeff,
On Fri, 17 Nov 2000, Jeff Garzik wrote:
IIRC, this came up a long time ago WRT Apache, which made a lot of
gettimeofday() calls. Someone (Linus?) proposed the solution of a
'magic page' which holds information like gettimeofday() stuff, but
could be handled much more rapidly than a
Hi Tigran,
On Fri, 17 Nov 2000, Tigran Aivazian wrote:
On Fri, 17 Nov 2000, Andi Kleen wrote:
[of course rdtsc only works properly on UP or with bind_cpu()]
I thought Linux kernel does synchronize them on boot? So, you are
saying I cannot rely on this being 100% correct?
Yes, it does so
Hi Andrea,
On Fri, 17 Nov 2000, Andrea Arcangeli wrote:
So as worse you'll have to wait x86-64 to get that lightweight
vgettimeofday.
Could I get this for i686? :-)
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Fri, 17 Nov 2000, [EMAIL PROTECTED] wrote:
If I rememeber correctly there where some problems with
SHM handling still left to resolve...
Nope.
Greetings
Christoph
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Hi Rik,
On Thu, 16 Nov 2000, Rik van Riel wrote:
> On 16 Nov 2000, Christoph Rohland wrote:
>> Also we have to make sure to derefence the swap entry if the
>> last reference is in the shm segmant table .
>
> Why is this?
Because you never get a page fault on the shm s
Oh, I missed one point: we need to handle the swapout of nonattached
pages: in shm you can detach the last user and the segment with
content is still around. So we have to scan the shm objects themselves
also. Should We could do this in the same loop as we scan the mm's?
Also we have to make
Hi Rik,
On Thu, 16 Nov 2000, Rik van Riel wrote:
> On 16 Nov 2000, Christoph Rohland wrote:
>> So in shm_swap_out I check if the page is already in the swap
>> cache. If not I put the page into it and note the swap entry in
>> the shadow pte of shm. Right?
>
&g
Hi Rik,
On Wed, 15 Nov 2000, Rik van Riel wrote:
> On 15 Nov 2000, Christoph Rohland wrote:
> You really want to have it in the swap cache, so we have
> a place for it allocated in cache, etc...
>
> Basically, when we unmap it in try_to_swap_out(), we
> should add the page
Hi Rik,
On Wed, 15 Nov 2000, Rik van Riel wrote:
On 15 Nov 2000, Christoph Rohland wrote:
You really want to have it in the swap cache, so we have
a place for it allocated in cache, etc...
Basically, when we unmap it in try_to_swap_out(), we
should add the page to the swap cache, and when
Hi Rik,
On Thu, 16 Nov 2000, Rik van Riel wrote:
On 16 Nov 2000, Christoph Rohland wrote:
So in shm_swap_out I check if the page is already in the swap
cache. If not I put the page into it and note the swap entry in
the shadow pte of shm. Right?
Exactly. And I'll change page_launder
Oh, I missed one point: we need to handle the swapout of nonattached
pages: in shm you can detach the last user and the segment with
content is still around. So we have to scan the shm objects themselves
also. Should We could do this in the same loop as we scan the mm's?
Also we have to make
Hi Rik,
On Thu, 16 Nov 2000, Rik van Riel wrote:
On 16 Nov 2000, Christoph Rohland wrote:
Also we have to make sure to derefence the swap entry if the
last reference is in the shm segmant table .
Why is this?
Because you never get a page fault on the shm segmants. So you never
Hi Rik,
On Wed, 15 Nov 2000, Rik van Riel wrote:
> On 15 Nov 2000, Christoph Rohland wrote:
>
>> - shm_swap is called from swap_out. Actually on my machine after a
>>while it only gets called without __GFP_IO set, which means it
>>will not do anything which
Hi Rik et al,
here I am again. I investigated more into the shm swapping in 2.4 and
discovered the following things:
- shm_swap is called from swap_out. Actually on my machine after a
while it only gets called without __GFP_IO set, which means it will
not do anything which again leads to
201 - 300 of 380 matches
Mail list logo
