Re: OT: malloc [era: Re: OT Squid]
On Fri, Jan 18, 2002 at 11:18:24AM +0100, Samu wrote:
> On Fri, Jan 18, 2002 at 01:27:49AM +0100, Daniele Cruciani wrote:
> > On Thu, Jan 17, 2002 at 09:42:35PM +0100, Samu wrote:
> > > no che centra ?
> > > qui si parla di strategie di allocazione per evitare di avere la memoria
> > > frammentata e che quindi risulti + piena di quello che e' ... tutto
> > > qua.
> >
> > ?? non ho capito niente,
> grazie :-))
>
> > comunque la frammentazione c'e' se si chiama
> > una free() non una malloc()
> non necessariamente, specie in un contesto multitasking ....
> per il tuo processo che fa una malloc ci sono due processi che fanno
> una free o viceversa ... in questo contesto la frammentazione
> capita molto spesso .
Ora ho capito e ho capito perche' e' ottimistica, ma non e' mica cosi
evidente dalla man
>
> > > beh se la strategia di allocazione e' buona serve abbastanza
> >
> > bisognerebbe mettersi tutti daccordo:
> >
> > - processi A,B vede 10M liberi.
> >
> > - processi A,B alloca 2M.
> >
> > va bene, ma se i processi sono 6 o 15 o 100?
> si procede col riempire tutta la memoria virtuale (quindi ram e swap)
> quando tutto e' pieno ... inizi a trovarti scritto
> "Resource temporarily unavailable" e il kernel parte con la "roulette russa"
> e ammazza processi a caso (non sono sicuro se a caso comunque li vedi su
> console)
:) non e' certo una consolazione vederlo sulla console (se poi sei
sulla console).
> >
> > Se le cose stanno cosi' penso che la cosa migliore per servizi critici
> > sia di avere server dedicati che fanno poco piu' di una cosa e non
> > occupano mai piu' (100-((max_lung_blocco)*nserver)/sysmem)% di
> > memoria,
>
> beh questo e' lapalissiano :-))
>
> > dove max_lung_blocco e' la lunghezza massima di un blocco
> > allocato da un qualunque processo, nserver e' il numero di processi
> > che possono allocare memoria (10 dovrebbe andare) e sysmem e'
> > ovviamente la memoria totale. Questa e' la strategia buona?
>
>
> e' una strategia ... adottata anche tramite ulimit
setrlimit/getrlimit, comunque un' altra e' partire, accaparrarsi tutta
la memoria che si ritiene necessaria, e gestirla per fatti propri. E'
un po' come riscriversi un O.S., ma puo' valerne la pena (una delle
versioni di Emacs fa' qualcosa simile): non si deve perdere tempo con
controlli, e comunque per garantire buone prestazioni e' meglio sapere
dove si trovano i dati (in swap o in memoria reale).
>
> ps. se non mi capisci stavolta mi arrabbio :-)))
beh, ho capito, ma poi mica tanto, che vuol dire "quando malloc
restituisce NULL non e' garantito che la memoria sia realmente
disponibile": quando lo vengo a sapere? al primo byte che cerco di
allocare, a meta' o anche all'ultima pagina?
ho capito che sara' meglio dare un'occhiata al kernel.
ciao,
Daniele.
Reply to: