On Iau, 2005-08-04 at 15:48 +0100, Hugh Dickins wrote:
> On Thu, 4 Aug 2005, Matti Aarnio wrote:
> >
> > SHM resources are non-swappable, thus I would not by default
> > let user programs go and allocate very much SHM spaces at all.
>
> No, SHM resources are swappable.
Large limits as oracle nee
Andi Kleen wrote on Thursday, August 04, 2005 3:54 PM
> > This might be too low on large system. We usually stress shm pretty hard
> > for db application and usually use more than 87% of total memory in just
> > one shm segment. So I prefer either no limit or a tunable.
>
> With large system you
Andi Kleen wrote on Thursday, August 04, 2005 6:24 AM
> I think we should just get rid of the per process limit and keep
> the global limit, but make it auto tuning based on available memory.
> That is still not very nice because that would likely keep it < available
> memory/2, but I suspect data
On Thu, Aug 04, 2005 at 03:49:37PM -0700, Chen, Kenneth W wrote:
> Andi Kleen wrote on Thursday, August 04, 2005 6:24 AM
> > I think we should just get rid of the per process limit and keep
> > the global limit, but make it auto tuning based on available memory.
> > That is still not very nice beca
On Thu, Aug 04, 2005 at 05:20:40PM +0300, Matti Aarnio wrote:
> SHM resources are non-swappable, thus I would not by default
Not true.
> let user programs go and allocate very much SHM spaces at all.
> Such is usually spelled as: "denial-of-service-attack"
> For that reason I would not raise buil
On Thu, Aug 04, 2005 at 03:23:38PM +0200, Andi Kleen wrote:
> On Thu, Aug 04, 2005 at 02:19:21PM +0100, Hugh Dickins wrote:
> > On Thu, 4 Aug 2005, Andi Kleen wrote:
> >
> > > I noticed that even 64bit architectures have a ridiculously low
> > > max limit on shared memory segments by default:
> >
On Thu, 4 Aug 2005, Matti Aarnio wrote:
>
> SHM resources are non-swappable, thus I would not by default
> let user programs go and allocate very much SHM spaces at all.
No, SHM resources are swappable.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Thu, Aug 04, 2005 at 02:19:21PM +0100, Hugh Dickins wrote:
...
> > Even on 32bit architectures it is far too small and doesn't
> > make much sense. Does anybody remember why we even have this limit?
>
> To be like the UNIXes.
:)
...
> Anton proposed raising the limits last autumn, but I was
On Thu, Aug 04, 2005 at 02:19:21PM +0100, Hugh Dickins wrote:
> On Thu, 4 Aug 2005, Andi Kleen wrote:
>
> > I noticed that even 64bit architectures have a ridiculously low
> > max limit on shared memory segments by default:
> >
> > #define SHMMAX 0x200 /* max shared seg size
On Thu, 4 Aug 2005, Andi Kleen wrote:
> I noticed that even 64bit architectures have a ridiculously low
> max limit on shared memory segments by default:
>
> #define SHMMAX 0x200 /* max shared seg size (bytes) */
> #define SHMMNI 4096 /* max num of segs s
On Thu, 4 Aug 2005, Andi Kleen wrote:
>
> I noticed that even 64bit architectures have a ridiculously low
> max limit on shared memory segments by default:
>
> #define SHMMAX 0x200 /* max shared seg size (bytes) */
> #define SHMMNI 4096 /* max num of segs
11 matches
Mail list logo
