[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] 64 K processes
Mistake : 1,5 MB must be read 1,5 GB !!!
----- Original Message -----
From: Christophe <christophe.avoinne@laposte.net>
To: <f-cpu@seul.org>
Sent: Tuesday, March 05, 2002 5:39 PM
Subject: [f-cpu] 64 K processes
> ok ok I misunderstood :)
>
> Well suppose that 64 K processES are running, do you compute how much it
takes
> as physical memory for all 64 K processes if we use a hierachical paging for
> example ?
>
> Ok take an example from ia32 :
>
> paging is 2-level :
>
> pde = pdbr[virtaddr(31..22)].pde;
> pte = pde[virtaddr(21..12)].pte;
> physaddr = pte.pfn + virtaddr(11..0);
>
> So for 64 K processes we need 64 K pdbrs, i.e, 64 K x 4 KB = 256 MB (ouch !
our
> pdbrs will take 256 MB).
>
> Now if each process has, say, a 16 MB virtual space, we also need 16 MB / 4
MB
> for pdes, i.e, 4 pdes and 16 MB / 4 KB for ptes, i.e, 4 K ptes. I'm speaking
> about the worst case where all page frames are not shared !!!
>
> So for 64 K processes we get at least 256 MB + (64 K x 4 x 4 KB) = 512 MB +
> 1024 MB = 1,5 MB if we suppose all ptes have invalid page frame ! quite
> impressive isn't it ?
>
> well my computer can handle only a max of 1,5 MB so using 64 K processes with
> an average of 16 MB virtal space is impossible on my computer.
>
> ----- Original Message -----
> From: Nicolas Boulay <nicolas.boulay@ifrance.com>
> To: <f-cpu@seul.org>
> Sent: Tuesday, March 05, 2002 3:32 PM
> Subject: Rep:Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed
> cache ?
>
>
> I wrote 64 K process, not 64 KB. It's just because i'm lazy to write
> 65535 as Marco suggest it.
> Sorry, Christophe.
>
> nicO
>
> -----Message d'origine-----
> De: "Christophe" <christophe.avoinne@laposte.net>
> A: <f-cpu@seul.org>
> Date: 05/03/02
> Objet: Re: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed
> cache ?
>
> 64 KB process is not enough but threads can surely use less than 64 KB.
>
> I prefer to speak about teams and threads. I consider a team as a
> collection of
> threads sharing the same address space and resources. The minimal
> process
> (without pthread) is quite like a team in fact with one thread. If you
> take a
> big application a 64 KB space would be largely insufficient even if
> using
> several threads because code can exceed 64 KB !
>
> ----- Original Message -----
> From: Nicolas Boulay <nicolas.boulay@ifrance.com>
> To: <f-cpu@seul.org>
> Sent: Tuesday, March 05, 2002 9:17 AM
> Subject: Rep:Re: Rep:Re: [f-cpu] virtually or physically-addressed cache
> ?
>
>
> Nowadays isn't possible to create long term computer which manage only 4
> Gb (it's the current physical limit of the pc)! 64 K process it's far
> enough but it should address 1 To at least ! (nowdays big machine
> address 64 Go)
>
> nicO
>
> -----Message d'origine-----
> De: "Marco Al" <marco@simplex.nl>
> A: <f-cpu@seul.org>
> Date: 05/03/02
> Objet: Re: Rep:Re: [f-cpu] virtually or physically-addressed cache ?
>
> From: "Michael Riepe" <michael@stud.uni-hannover.de>
>
> > The main drawback is that you'll have to know the number of processes
> and
> > the maximum total memory size in advance. You can do that in an
> embedded
> > system (works pretty well there), but not in a general-purpose OS.
>
> There is a difference between what you can do and what you can
> efficiently
> do. In such a scheme if you have say a 48 bit global address space and
> you
> are using 32 bit addresses with byte addressing you can efficiently run
> 65K
> processes with 2 GB address spaces each, that is not to say you cant run
> more you will just have to make changes in the global address space and
> either flush the cache or walk it to invalidate affected cachelines each
> time a process not on the list is "swapped" in. Would even a hard limit
> of
> 65K 4GB address spaces really present any issue for a general purpose OS
> though? :)
>
> Marco
>
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu in the body. http://f-cpu.seul.org/
>
>
> ________________________________________________________________________
> ______
> ifrance.com, l'email gratuit le plus complet de l'Internet !
> vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> http://www.ifrance.com/_reloc/email.emailif
>
>
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu in the body. http://f-cpu.seul.org/
>
>
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu in the body. http://f-cpu.seul.org/
>
>
>
______________________________________________________________________________
> ifrance.com, l'email gratuit le plus complet de l'Internet !
> vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> http://www.ifrance.com/_reloc/email.emailif
>
>
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu in the body. http://f-cpu.seul.org/
>
> *************************************************************
> To unsubscribe, send an e-mail to majordomo@seul.org with
> unsubscribe f-cpu in the body. http://f-cpu.seul.org/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/