Re: [PATCH] kanoj-mm21-2.3.23 alow larger sizes to shmget()

[Christoph Rohland <hans-christoph.rohland@sap.com>]

kanoj@google.engr.sgi.com (Kanoj Sarcar) writes:

> > 
> > 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()).

Why should we make it arch dependend if we can tune it at runtime?

> 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.

I preferred not to clutter the proc/sys/kernel namespace, but this is
arguable. I think tuning these parameters belongs together and can
easily be done in one file. Especially since you can tune the most
import one alone. (SHMMAX is the first)

> 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 ...

It is crucial for big machines especially with highmem support. I
still try to get 2.3.25 to swap out shm pages. There was something
introduced after 2.3.22 which prevents shm pages to swap out (w/o my
patch). At least 2.3.25 survives running out of memory with high
memory so I can investigate.

        Christoph
--
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/