From: kanoj@google.engr.sgi.com (Kanoj Sarcar)
To: Christoph Rohland <hans-christoph.rohland@sap.com>
Cc: torvalds@transmeta.com, linux-mm@kvack.org
Subject: Re: [PATCH] kanoj-mm21-2.3.23 alow larger sizes to shmget()
Date: Tue, 2 Nov 1999 13:24:54 -0800 (PST) [thread overview]
Message-ID: <199911022124.NAA93231@google.engr.sgi.com> (raw)
In-Reply-To: <qwwwvs1i5h1.fsf@sap.com> from "Christoph Rohland" at Nov 2, 99 10:54:18 am
>
> Since glibc is encapsulating these calls and headers, we could perhaps
> work with compatibility version. E.g. making shmget and shmctl a real
> system call and converting the structures in sys_ipc to the old ones
> for old libraries?
>
> BTW I did some work to make the clean up the shm coding and make the
> limites sysctleable. It also avoids vmalloc for the page tables. The
> latter is really important for big servers. We run out of vm-space on
> some benchmarks. I appended the patch against 2.3.24. I could not
> finally test this patch since shm swapping has apparently a race
> condition on segment deletion introduced with the smp version. I am
> still investigating on that. But perhaps we could incorporate this
> patch anyways. It did survive stress testing shm-swapping as long as I
> do not remove segments.
>
The clean up code is similar to what I posted at
http://humbolt.geo.uu.nl/lists/linux-mm/1999-06/msg00071.html
previously. Although, I would point out that SHMMAX probably belongs
to the asm/* header file (specially, with the size_t size parameter
to shmget()).
The sysctl idea is good, although you need to clean up the code, and
make 2 new nodes /proc/sys/kernel/* for ease of use.
The removal of struct shmid_kernel from shm.h to a private header
file, or to shm.c is a very good idea. This has no business being
user visible. Cleanups like this go a long way in creating a clean
ddi/dki ...
The removal of vmalloc() from the shm.c sounds good in principle,
although I haven't really reviewed your code in any detail ...
Thanks.
Kanoj
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
next prev parent reply other threads:[~1999-11-02 21:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-10-28 22:04 [PATCH] kanoj-mm21-2.3.23 alow larger sizes to shmget() Kanoj Sarcar
1999-11-01 9:41 ` Christoph Rohland
1999-11-01 17:00 ` Kanoj Sarcar
1999-11-02 9:54 ` Christoph Rohland
1999-11-02 21:24 ` Kanoj Sarcar [this message]
1999-11-02 21:45 ` Christoph Rohland
1999-11-02 21:56 ` Kanoj Sarcar
1999-11-02 22:09 ` Christoph Rohland
1999-11-03 9:06 ` Christoph Rohland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199911022124.NAA93231@google.engr.sgi.com \
--to=kanoj@google.engr.sgi.com \
--cc=hans-christoph.rohland@sap.com \
--cc=linux-mm@kvack.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.