The following testcase brought down 2.4.17 mainline on an
8-way P-III 700MHz machine with 12GB of RAM. The last thing
logged from it was a LowFree of 2MB with 9GB of highmem free
after something like 6-8 hours of pounding away, at which
time the machine stopped responding (IIRC it was given ~12
hours to echo another character).
This testcase is a blatant attempt to fill the direct-mapped
portion of the kernel virtual address space with process pagetables.
It was suspected such a thing was happening in another failure scenario
which is what motivated me to devise this testcase. I believe a fix
already exists (i.e. aa's ptes in highmem stuff) though I've not yet
verified its correct operation here.
The driver script was this:
#!/bin/sh
for n in `seq 0 1023`
do
./death &
done
and the C program was the following:
#define __USE_LARGEFILE64
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#define __USE_LARGEFILE64
#include <fcntl.h>
#include <errno.h>
#define MAPPING_START 0x20000000
#define MAPPING_SIZE (0x80000000/sizeof(unsigned long))
#define MAPPING_END (MAPPING_START + MAPPING_SIZE*sizeof(unsigned long))
int main(void)
{
int fd;
unsigned long *data = NULL;
unsigned long try = 64;
unsigned long k = 0;
fd = open("/home/wli/bench/mapfile", O_RDWR|O_LARGEFILE);
if (fd < 0) {
perror("death");
printf("could not open mapfile!\n");
exit(1);
}
data = mmap((void *)MAPPING_START,
MAPPING_SIZE,
PROT_READ|PROT_WRITE,
MAP_FIXED | MAP_SHARED,
fd,
0);
if (!try || data == MAP_FAILED) {
printf("mmap() failed, tries = %lu!\n", 64 - try + 1);
exit(1);
}
printf("managed to mmap() at %p\n", (void *)data);
sleep(60);
try = 0;
while (1) {
printf("entered iteration %lu\n", k);
data[k++] = try++;
k %= MAPPING_SIZE;
if (k >= MAPPING_SIZE-1)
k = 0;
}
return 0;
}
Cheers,
Bill
On Fri, Feb 15, 2002 at 09:59:45AM +0100, Daniel Phillips wrote:
> As you described it to me on irc, this demonstration turns up a
> considerably worse problem than just having insufficient space for
> page tables - the system locks up hard instead of doing anything
> reasonable on page table-related oom. It's wrong that the system
> should behave this way, it is after all, just an oom.
> Now that basic stability issues seem to be under control, perhaps
> it's time to give the oom problem the attention it deserves?
It's not just OOM:
HighTotal: 11927512 kB
HighFree: 9423076 kB
LowTotal: 709456 kB
LowFree: 2208 kB
SwapTotal:ead from remote host elm3b78.eng: Connection reset by peer
In my mind, this is a basic stability issue.
Cheers,
Bill
On February 15, 2002 05:51 am, William Lee Irwin III wrote:
> The following testcase brought down 2.4.17 mainline on an
> 8-way P-III 700MHz machine with 12GB of RAM. The last thing
> logged from it was a LowFree of 2MB with 9GB of highmem free
> after something like 6-8 hours of pounding away, at which
> time the machine stopped responding (IIRC it was given ~12
> hours to echo another character).
>
> This testcase is a blatant attempt to fill the direct-mapped
> portion of the kernel virtual address space with process pagetables.
> It was suspected such a thing was happening in another failure scenario
> which is what motivated me to devise this testcase. I believe a fix
> already exists (i.e. aa's ptes in highmem stuff) though I've not yet
> verified its correct operation here.
As you described it to me on irc, this demonstration turns up a
considerably worse problem than just having insufficient space for
page tables - the system locks up hard instead of doing anything
reasonable on page table-related oom. It's wrong that the system
should behave this way, it is after all, just an oom.
Now that basic stability issues seem to be under control, perhaps
it's time to give the oom problem the attention it deserves?
--
Daniel
On February 18, 2002 02:38 am, Andrea Arcangeli wrote:
> On Fri, Feb 15, 2002 at 09:59:45AM +0100, Daniel Phillips wrote:
> > On February 15, 2002 05:51 am, William Lee Irwin III wrote:
> > > The following testcase brought down 2.4.17 mainline on an
> > > 8-way P-III 700MHz machine with 12GB of RAM. The last thing
> > > logged from it was a LowFree of 2MB with 9GB of highmem free
> > > after something like 6-8 hours of pounding away, at which
> > > time the machine stopped responding (IIRC it was given ~12
> > > hours to echo another character).
> > >
> > > This testcase is a blatant attempt to fill the direct-mapped
> > > portion of the kernel virtual address space with process pagetables.
> > > It was suspected such a thing was happening in another failure scenario
> > > which is what motivated me to devise this testcase. I believe a fix
> > > already exists (i.e. aa's ptes in highmem stuff) though I've not yet
> > > verified its correct operation here.
> >
> > As you described it to me on irc, this demonstration turns up a
> > considerably worse problem than just having insufficient space for
> > page tables - the system locks up hard instead of doing anything
> > reasonable on page table-related oom. It's wrong that the system
> > should behave this way, it is after all, just an oom.
> >
> > Now that basic stability issues seem to be under control, perhaps
> > it's time to give the oom problem the attention it deserves?
>
> My tree doesn't lock up hard even without pte-highmem applied. The task
> gets killed.
Well, the obvious question is: Why Isn't It In Mainline???
> backout pte-highmem, try the same testcase again on my tree
> and you'll see. The oom handling in mainline is deadlock prone, I always
> known this and that's why I always rejected it. Nobody but me
> acklowledged this problem
Lots of people acknowleged it, it seems just one guy fixed it.
> and I spent quite an amount of time convincing
> mainline maintainers about those deadlock flaws of the mainline approch
> but I failed so I giveup waiting for a report like this, just like with
> all the other stuff that is now in my vm patch, 90% of it I tried to
> push it separately into mainline before having to accumulate it.
What I'd suggest is, just post a list of each item outstanding item that
haven't been pushed to mainline, and an explanation of which problem it
fixes.
Incorrect oom accounting has been a bleeding wound for well over a year,
and if you've got a fix that's provably correct...
Marcelo?? Is this just a stupid communication problem?
--
Daniel
On Mon, Feb 18, 2002 at 01:59:42PM +0100, Daniel Phillips wrote:
> On February 18, 2002 01:27 pm, Andrea Arcangeli wrote:
> > Agreed, this is why I fighted with Linus and Marcelo trying to convince
> > them not to reintroduce the loop crap into the allocator that leads to
> > all sort of oom deadlocks because we lack the knowledge on the amount of
> > freeable pages (I even re-read the emails about such stuff in the thread
> > "VM tweaks" to be sure I was remembering right). OTOH, I really cannot
> > complain, they included so much stuff from my tree that even if we
> > disagreed on something at the end I don't mind :). And this is probably
> > also why I don't like very much to restart those threads about oom
> > deadlocks, I know my way is the only right way (i.e. non deadlock prone)
> > possible, and I live with it just fine.
> >
> > The only way we can learn if a page or a mapping is freeable or not, is
> > by trying to free it and by checking if we failed or not. We cannot know
> > in another manner, only checking the size of the caches or the amount of
> > the swap still unused is totally meaningless and broken. That's
> > unfortunate but that's how all linux kernels I know of works, and what I
> > did in my tree at the moment is the only possible way to avoid deadlocks
> > without having to do a major rework on the accounting side.
>
> Could you describe your page table deadlock-avoidance algorithm in more
> detail please?
There is nothing specific with the pagetables. If the lowmem was eat by
skb instead of ptes you'd deadlock the very same way. The kernel will
just see lots of cache in highmem and of swap available (not to tell the
kernel never knows how much of such cache is really freeable or how much
of the mappings are swappable and that's the very next problem that will
leads to the same deadlock) and it will think there's "freeable" memory
available and it will keep looping. That's simply plain broken. The
only way if there's something freeable is to try to free it and if we
fail we say "oom". You cannot say if there's something freeable by
checking the cache size or the number of free swap pages, no-way.
If in 2.5 we want perfect accounting of freeable resources instead, fine
with me (that would math guarantee to never fail allocations if there's
at least one page freeable, while right now you only can calculate a
probabilistic measure), but it has to be _perfect_, and with 2.4 there
isn't such perfect accounting, so we definitely cannot rely on cache
size and swap available to know if to trigger oom or not. That's totally
broken and it will deadlock. I care about those minor theorical things
too, I want everything calculated and under control, I hate
approximations that can leads to deadlocks, and it pays off eventually.
Andrea
On February 18, 2002 01:27 pm, Andrea Arcangeli wrote:
> Agreed, this is why I fighted with Linus and Marcelo trying to convince
> them not to reintroduce the loop crap into the allocator that leads to
> all sort of oom deadlocks because we lack the knowledge on the amount of
> freeable pages (I even re-read the emails about such stuff in the thread
> "VM tweaks" to be sure I was remembering right). OTOH, I really cannot
> complain, they included so much stuff from my tree that even if we
> disagreed on something at the end I don't mind :). And this is probably
> also why I don't like very much to restart those threads about oom
> deadlocks, I know my way is the only right way (i.e. non deadlock prone)
> possible, and I live with it just fine.
>
> The only way we can learn if a page or a mapping is freeable or not, is
> by trying to free it and by checking if we failed or not. We cannot know
> in another manner, only checking the size of the caches or the amount of
> the swap still unused is totally meaningless and broken. That's
> unfortunate but that's how all linux kernels I know of works, and what I
> did in my tree at the moment is the only possible way to avoid deadlocks
> without having to do a major rework on the accounting side.
Could you describe your page table deadlock-avoidance algorithm in more
detail please?
--
Daniel
On Fri, Feb 15, 2002 at 09:59:45AM +0100, Daniel Phillips wrote:
> On February 15, 2002 05:51 am, William Lee Irwin III wrote:
> > The following testcase brought down 2.4.17 mainline on an
> > 8-way P-III 700MHz machine with 12GB of RAM. The last thing
> > logged from it was a LowFree of 2MB with 9GB of highmem free
> > after something like 6-8 hours of pounding away, at which
> > time the machine stopped responding (IIRC it was given ~12
> > hours to echo another character).
> >
> > This testcase is a blatant attempt to fill the direct-mapped
> > portion of the kernel virtual address space with process pagetables.
> > It was suspected such a thing was happening in another failure scenario
> > which is what motivated me to devise this testcase. I believe a fix
> > already exists (i.e. aa's ptes in highmem stuff) though I've not yet
> > verified its correct operation here.
>
> As you described it to me on irc, this demonstration turns up a
> considerably worse problem than just having insufficient space for
> page tables - the system locks up hard instead of doing anything
> reasonable on page table-related oom. It's wrong that the system
> should behave this way, it is after all, just an oom.
>
> Now that basic stability issues seem to be under control, perhaps
> it's time to give the oom problem the attention it deserves?
My tree doesn't lock up hard even without pte-highmem applied. The task
gets killed. backout pte-highmem, try the same testcase again on my tree
and you'll see. The oom handling in mainline is deadlock prone, I always
known this and that's why I always rejected it. Nobody but me
acklowledged this problem and I spent quite an amount of time convincing
mainline maintainers about those deadlock flaws of the mainline approch
but I failed so I giveup waiting for a report like this, just like with
all the other stuff that is now in my vm patch, 90% of it I tried to
push it separately into mainline before having to accumulate it.
Andrea
On Mon, Feb 18, 2002 at 02:59:26AM +0100, Daniel Phillips wrote:
> On February 18, 2002 02:38 am, Andrea Arcangeli wrote:
> > On Fri, Feb 15, 2002 at 09:59:45AM +0100, Daniel Phillips wrote:
> > > On February 15, 2002 05:51 am, William Lee Irwin III wrote:
> > > > The following testcase brought down 2.4.17 mainline on an
> > > > 8-way P-III 700MHz machine with 12GB of RAM. The last thing
> > > > logged from it was a LowFree of 2MB with 9GB of highmem free
> > > > after something like 6-8 hours of pounding away, at which
> > > > time the machine stopped responding (IIRC it was given ~12
> > > > hours to echo another character).
> > > >
> > > > This testcase is a blatant attempt to fill the direct-mapped
> > > > portion of the kernel virtual address space with process pagetables.
> > > > It was suspected such a thing was happening in another failure scenario
> > > > which is what motivated me to devise this testcase. I believe a fix
> > > > already exists (i.e. aa's ptes in highmem stuff) though I've not yet
> > > > verified its correct operation here.
> > >
> > > As you described it to me on irc, this demonstration turns up a
> > > considerably worse problem than just having insufficient space for
> > > page tables - the system locks up hard instead of doing anything
> > > reasonable on page table-related oom. It's wrong that the system
> > > should behave this way, it is after all, just an oom.
> > >
> > > Now that basic stability issues seem to be under control, perhaps
> > > it's time to give the oom problem the attention it deserves?
> >
> > My tree doesn't lock up hard even without pte-highmem applied. The task
> > gets killed.
>
> Well, the obvious question is: Why Isn't It In Mainline???
Because mainline maintainers disagreed. The argument is been "the only
way to avoid suprious oom failures is to reintroduce such infinite
loop". oom deadlocks was the last of my worries (as far as my tree
doesn't deadlock) given the rest of the agreements, so I giveup waiting
somebody to complain (as with everything else it eventually happens when
something can deadlock) and really I've no fun to return discussing
this.
> > backout pte-highmem, try the same testcase again on my tree
> > and you'll see. The oom handling in mainline is deadlock prone, I always
> > known this and that's why I always rejected it. Nobody but me
> > acklowledged this problem
>
> Lots of people acknowleged it, it seems just one guy fixed it.
As far I can tell this is the first oom deadlock email I read on l-k
(but I unfortunately don't have time to read every single email on l-k
so I may have missed some). The others were too early deadlocks (less
severe).
> > and I spent quite an amount of time convincing
> > mainline maintainers about those deadlock flaws of the mainline approch
> > but I failed so I giveup waiting for a report like this, just like with
> > all the other stuff that is now in my vm patch, 90% of it I tried to
> > push it separately into mainline before having to accumulate it.
>
> What I'd suggest is, just post a list of each item outstanding item that
> haven't been pushed to mainline, and an explanation of which problem it
> fixes.
I'm out of sync at the moment, and I've many things pending to do, so
I'm afraid I won't have much time for it.
> Incorrect oom accounting has been a bleeding wound for well over a year,
> and if you've got a fix that's provably correct...
>
> Marcelo?? Is this just a stupid communication problem?
It wasn't a communication problem.
Andrea
On Sun, Feb 17, 2002 at 07:26:44PM -0800, William Lee Irwin III wrote:
> On Mon, Feb 18, 2002 at 02:38:00AM +0100, Andrea Arcangeli wrote:
> > My tree doesn't lock up hard even without pte-highmem applied. The task
> > gets killed. backout pte-highmem, try the same testcase again on my tree
> > and you'll see. The oom handling in mainline is deadlock prone, I always
> > known this and that's why I always rejected it. Nobody but me
> > acklowledged this problem and I spent quite an amount of time convincing
> > mainline maintainers about those deadlock flaws of the mainline approch
> > but I failed so I giveup waiting for a report like this, just like with
> > all the other stuff that is now in my vm patch, 90% of it I tried to
> > push it separately into mainline before having to accumulate it.
>
> This is a basic issue. Does the kernel run or does it crash?
It keeps running, there's no way to stop it. Go ahead and try it. I tell
you I'm sure because when I wrote pte-highmem, before realizing the
problem with the pagetables, people was very happy with my tree because
it was the first one not deadlocking, but instead oom killing one of those
pagetable hogs. Now thanks to pte-highmem all their problems are gone
and they have no limit any longer (other than cpu resources).
> Mainline can't live without it. Nothing can.
Agreed, this is why I fighted with Linus and Marcelo trying to convince
them not to reintroduce the loop crap into the allocator that leads to
all sort of oom deadlocks because we lack the knowledge on the amount of
freeable pages (I even re-read the emails about such stuff in the thread
"VM tweaks" to be sure I was remembering right). OTOH, I really cannot
complain, they included so much stuff from my tree that even if we
disagreed on something at the end I don't mind :). And this is probably
also why I don't like very much to restart those threads about oom
deadlocks, I know my way is the only right way (i.e. non deadlock prone)
possible, and I live with it just fine.
The only way we can learn if a page or a mapping is freeable or not, is
by trying to free it and by checking if we failed or not. We cannot know
in another manner, only checking the size of the caches or the amount of
the swap still unused is totally meaningless and broken. That's
unfortunate but that's how all linux kernels I know of works, and what I
did in my tree at the moment is the only possible way to avoid deadlocks
without having to do a major rework on the accounting side.
Andrea
On Mon, Feb 18, 2002 at 02:38:00AM +0100, Andrea Arcangeli wrote:
> My tree doesn't lock up hard even without pte-highmem applied. The task
> gets killed. backout pte-highmem, try the same testcase again on my tree
> and you'll see. The oom handling in mainline is deadlock prone, I always
> known this and that's why I always rejected it. Nobody but me
> acklowledged this problem and I spent quite an amount of time convincing
> mainline maintainers about those deadlock flaws of the mainline approch
> but I failed so I giveup waiting for a report like this, just like with
> all the other stuff that is now in my vm patch, 90% of it I tried to
> push it separately into mainline before having to accumulate it.
This is a basic issue. Does the kernel run or does it crash?
Mainline can't live without it. Nothing can.
Cheers,
Bill
On Mon, 18 Feb 2002, Daniel Phillips wrote:
> On February 18, 2002 02:38 am, Andrea Arcangeli wrote:
> > On Fri, Feb 15, 2002 at 09:59:45AM +0100, Daniel Phillips wrote:
> > > On February 15, 2002 05:51 am, William Lee Irwin III wrote:
> > > > The following testcase brought down 2.4.17 mainline on an
> > > > 8-way P-III 700MHz machine with 12GB of RAM. The last thing
> > > > logged from it was a LowFree of 2MB with 9GB of highmem free
> > > > after something like 6-8 hours of pounding away, at which
> > > > time the machine stopped responding (IIRC it was given ~12
> > > > hours to echo another character).
> > > >
> > > > This testcase is a blatant attempt to fill the direct-mapped
> > > > portion of the kernel virtual address space with process pagetables.
> > > > It was suspected such a thing was happening in another failure scenario
> > > > which is what motivated me to devise this testcase. I believe a fix
> > > > already exists (i.e. aa's ptes in highmem stuff) though I've not yet
> > > > verified its correct operation here.
> > >
> > > As you described it to me on irc, this demonstration turns up a
> > > considerably worse problem than just having insufficient space for
> > > page tables - the system locks up hard instead of doing anything
> > > reasonable on page table-related oom. It's wrong that the system
> > > should behave this way, it is after all, just an oom.
> > >
> > > Now that basic stability issues seem to be under control, perhaps
> > > it's time to give the oom problem the attention it deserves?
> >
> > My tree doesn't lock up hard even without pte-highmem applied. The task
> > gets killed.
>
> Well, the obvious question is: Why Isn't It In Mainline???
>
> > backout pte-highmem, try the same testcase again on my tree
> > and you'll see. The oom handling in mainline is deadlock prone, I always
> > known this and that's why I always rejected it. Nobody but me
> > acklowledged this problem
>
> Lots of people acknowleged it, it seems just one guy fixed it.
>
> > and I spent quite an amount of time convincing
> > mainline maintainers about those deadlock flaws of the mainline approch
> > but I failed so I giveup waiting for a report like this, just like with
> > all the other stuff that is now in my vm patch, 90% of it I tried to
> > push it separately into mainline before having to accumulate it.
>
> What I'd suggest is, just post a list of each item outstanding item that
> haven't been pushed to mainline, and an explanation of which problem it
> fixes.
>
> Incorrect oom accounting has been a bleeding wound for well over a year,
> and if you've got a fix that's provably correct...
>
> Marcelo?? Is this just a stupid communication problem?
Andrew talked with me about merging parts of -aa VM into mainline.
I guess he will be doing the job during the 2.4.19-pre cycle. Am I right
Andrew?
On Mon, Feb 18, 2002 at 02:38:00AM +0100, Andrea Arcangeli wrote:
> My tree doesn't lock up hard even without pte-highmem applied. The task
> gets killed. backout pte-highmem, try the same testcase again on my tree
> and you'll see. The oom handling in mainline is deadlock prone, I always
> known this and that's why I always rejected it. Nobody but me
> acklowledged this problem and I spent quite an amount of time convincing
> mainline maintainers about those deadlock flaws of the mainline approch
> but I failed so I giveup waiting for a report like this, just like with
> all the other stuff that is now in my vm patch, 90% of it I tried to
> push it separately into mainline before having to accumulate it.
Actually I'm a little more skeptical on a second reading:
(1) Which of the 1024 processes will it shoot again?
(2) Where is the OOM trigger again?
(3) Where is the accounting on space usage for page tables again?
(4) What is done to counteract the occcasional unswappable allocation
satisfied from ZONE_NORMAL exerting pressure over time again?
... and this isn't exactly a report, this is a testcase that takes down
machines without the appropriate fixes on demand in order to provide an
adequate demonstration of how some real-life workloads crash the kernel.
Hopefully I left out enough details to slow down the less ethical people;
if I didn't then I'm willing to hear advice on how to handle these things.
Alan, Linus, if there are recommended methods or fora, please let me know.
If I didn't know of pte-highmem already I would never had posted this in
a public forum until some kind of fix existed.
Also, if there are more blatant bugs like this one waiting for fixes
from your VM patch I would be very interested in getting a list
(privately) so that some kind of effort can be devoted to both pushing
the fixes to mainline and making sure these bugs either don't arise or
get fixed in -rmap.
Please send it encrypted.
Cheers,
Bill
On February 18, 2002 02:15 pm, Andrea Arcangeli wrote:
> On Mon, Feb 18, 2002 at 01:59:42PM +0100, Daniel Phillips wrote:
> > Could you describe your page table deadlock-avoidance algorithm in more
> > detail please?
>
> There is nothing specific with the pagetables. If the lowmem was eat by
> skb instead of ptes you'd deadlock the very same way. The kernel will
> just see lots of cache in highmem and of swap available (not to tell the
> kernel never knows how much of such cache is really freeable or how much
> of the mappings are swappable and that's the very next problem that will
> leads to the same deadlock) and it will think there's "freeable" memory
> available and it will keep looping. That's simply plain broken. The
> only way if there's something freeable is to try to free it and if we
> fail we say "oom". You cannot say if there's something freeable by
> checking the cache size or the number of free swap pages, no-way.
>
> If in 2.5 we want perfect accounting of freeable resources instead, fine
> with me (that would math guarantee to never fail allocations if there's
> at least one page freeable, while right now you only can calculate a
> probabilistic measure), but it has to be _perfect_, and with 2.4 there
> isn't such perfect accounting, so we definitely cannot rely on cache
> size and swap available to know if to trigger oom or not. That's totally
> broken and it will deadlock. I care about those minor theorical things
> too, I want everything calculated and under control, I hate
> approximations that can leads to deadlocks, and it pays off eventually.
You're right, we have to get serious about doing what it takes to have a
precise accounting of pinned memory. What are we going to do, count the
number of 1->2 and 2->1 transitions on page->count? Or should we have a
pin/unpin_page(page) api? Or what?
--
Daniel
Okay, I hereby place this testcase under the GPL:
/*
* death.c -- Testcase for pagetable memory management.
*
* Copyright (C) 2002 William Irwin
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
#define __USE_LARGEFILE64
#include <stdio.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/stat.h>
#include <sys/types.h>
#define __USE_LARGEFILE64
#include <fcntl.h>
#include <errno.h>
#define MAPPING_START 0x20000000
#define MAPPING_SIZE (0x80000000/sizeof(unsigned long))
#define MAPPING_END (MAPPING_START + MAPPING_SIZE*sizeof(unsigned long))
int main(void)
{
int fd;
unsigned long *data = NULL;
unsigned long try = 64;
unsigned long k = 0;
fd = open("/home/wli/bench/mapfile", O_RDWR|O_LARGEFILE);
if (fd < 0) {
perror("death");
printf("could not open mapfile!\n");
exit(1);
}
data = mmap((void *)MAPPING_START,
MAPPING_SIZE,
PROT_READ|PROT_WRITE,
MAP_FIXED | MAP_SHARED,
fd,
0);
if (!try || data == MAP_FAILED) {
printf("mmap() failed, tries = %lu!\n", 64 - try + 1);
exit(1);
}
printf("managed to mmap() at %p\n", (void *)data);
sleep(60);
try = 0;
while (1) {
printf("entered iteration %lu\n", k);
data[k++] = try++;
k %= MAPPING_SIZE;
if (k >= MAPPING_SIZE-1)
k = 0;
}
return 0;
}
On Mon, Feb 18, 2002 at 07:15:02PM -0500, Mark Hahn wrote:
>> fd = open("/home/wli/bench/mapfile", O_RDWR|O_LARGEFILE);
>
> well, speaking as a member of the GP, I resent having to give you an account ;)
>
Things like this are supposed to deter casual users from attempting to use
it on their own machines. There are also other issues I will not elaborate
that will prevent the testcase from running unless addressed.
Those who understand them, please do not publicly give directions on
how to address those issues.
Cheers,
Bill