Micah
Sat Aug 21 20:34:44 CDT 2004
I can imagine other reasons why it might be appealing to mess with MM,
though, besides laziness ;). For example, session-related memory in the
kernel is only going to be accessed from the context of a process running in
the given session, AFAIK. So, there ought to be little overhead (extra
pagetables, pagetable modifications, and TLB flushes) using a chunk of
system address space some aligned multiple of 4MB and switching it along
with the process address space. Since one session's worth of data ever need
be mapped at a time, perhaps this then would offer a significant savings in
system virtual address space, and thereby improved scalability on
highly-utilitzed terminal servers? (Too bad you can't easily swap the cache
like that!)
Anyone know any other interesting tidbits or any place I might turn for more
information? I'm actually gearing up for a hack of a similar sort, on our
old Win2k source license, so I'm trying to learn as much as possible about
the tradeoffs involved (especially ease of implementation!).
Thanks a lot!
--Micah Brodsky
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:%23sfzosphEHA.244@TK2MSFTNGP10.phx.gbl...
> From what I know, this was due to avoid rewriting win32k for Remote
> Desktop. Rewriting MM was simpler :)
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
>
http://www.storagecraft.com
>
> "Micah Brodsky" <eightyfivNOSPAM@PLEASEyahoo.com> wrote in message
> news:%23ZJAH6ohEHA.2544@TK2MSFTNGP10.phx.gbl...
> > Hey, folks.
> > Does anyone know of a good document or resource describing the goals and
> > design decisions behind the session space virtual memory block in the
> > kernel, why it was done the way it was? (And, maybe even how? although I
> > wouldn't expect as much to be public ;)
> >
> > Thanks a lot.
> > --Micah Brodsky
> >
> >
>
>