The problem with one lock for every physical page is that the sheer
number of locks gets to be too high. Again think about windows or any
operating system and our complaint about them, they require too much
memory to run. A lock per page is directly related to the operating
system's footprint. If you had 4K pages with 1GB of memory (std for most
PCs now) you will have 2^30 / 2^12 = 2^18 = 256k locks. If you assume
that each lock takes a few hundred bytes of storage then you are talking
on the order of megabytes of data for the lock storage alone that has to
be pinned and can never be evicted. So in terms of sheer storage the
overhead starts to kill you. If you think its a couple of megabytes here
and a couple of megabytes there ... it slowly starts to add up and you
get a large footprint and consumers start to complain.
In addition, consider the various I/O devices that have to interact with
the physical memory. In order to properly setup the DMA channels they
need to know that the memory is properly setup. It makes sense that
there is some overhead (i.e. acquiring one lock for the entire memory)
to setup the metadata for the transfer but having each i/o device try to
grab a lock causes a lot of contention in the machine in the critical path.
So I guess the short answer after all that long-winded aside about real
OSes is that in nachos it might be ok since its so small, but our goal
is to learn how real OSes work and design for them and not design for
the specific class project and in a real OS it is just too expensive to
lock every page.
Post by GeneOn part2, bullet 5 states that we should *not* use a separate Lock for
each page because that is highly inefficient.
We don't see how it would be inefficient if we have one lock for every
physical page. Can you clarify the inefficiency in doing that?