From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH] kanoj-mm21-2.3.23 alow larger sizes to shmget() References: <199911022124.NAA93231@google.engr.sgi.com> Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Christoph Rohland Date: 02 Nov 1999 22:45:00 +0100 In-Reply-To: kanoj@google.engr.sgi.com's message of "Tue, 2 Nov 1999 13:24:54 -0800 (PST)" Message-ID: Sender: owner-linux-mm@kvack.org Return-Path: To: Kanoj Sarcar Cc: Christoph Rohland , torvalds@transmeta.com, linux-mm@kvack.org List-ID: 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/