|
|
About ::
TODO ::
Blog ::
RSS ::
Old blog ::
Projects ::
GIT ::
Gallery ::
Notes
Sun, 14 Jan 2007
NPTL thread stack usage.
NPTL (as of glibc-2.5) uses following tricky stack usage model:
when new thread is created some stack must be allocated for it,
so NPTL stores cache of stacks, each of which has different size,
so when thread is created that cache is searched for the entry
with the nearest but bigger cache, if cache is found and it is
not that bigger than requested (it is less than 4 times bigger than requested),
it is returned to the user (and global variable which holds size
of the cached stacks is reduced). If there is no appropriate stack,
it is allocated from anonymous memory using mmap()
with at least MAP_PRIVATE | MAP_ANONYMOUS flags,
which in particular means that pages are not allocated at all,
but copy-on-write mechanism is used (i.e. real allocation happens
only when user writes to allocated pages).
Maximum size of the thread stack is 40 Mb, default value is taken
from rlimits.
Stack is guarded by some pages (if required) and part of it is used
as control block.
Simple and good model.
Exactly the same model will be used for stack allocation for M-on-N
threading model.
There is another interesting memory issue in NPTL - so called thread-local storage (aka TLS).
It allows to have for example global errno variable to be per-thread.
This requires to extend programming language (C and C++ have __thread variables)
and ELF header. Reasons to have thread-local storage are obvious and the main one is performance,
but it has too many problems with symbol lookups, object allocation and other issues (more
details can be found in this article),
so I will not implement it.
Furthermore, my library will be actually _trivial_ layer on top
of glibc, which will just provide _new_ symbols for programmers,
like new_write(), and if approach will be considered as good,
glibc maintainers (namely Ulrich Drepper,
with whom I had some discussion about kevent
(it looks like we still not 100% agree on all issues, but there was a major progress))
could adopt given design.
My library will use makecontext() and friends functions from
glibc as a basis,
which are actually just wrappers, which work with registers and other meaningfull for process
running information.
/devel/threading :: Link / Comments (0)
Meanwhile on flat development front.
As you have already found, I 90% completed hinged ceiling painting -
I selected shine orange colour to specify sleeping area (that is where
hinged ceiling is located), later I will paint the rest of the ceiling
likely into something calm like slightly blue or green. Kitchen
will have likely beige colours.
I also completed self-leveling floor filling everywhere except
half of the room, where developing materials are placed - I even
started to move in the room without shoes, although it is quite cold.
Seems, that I've fixed central heating radiator, or at least made it work
a bit better - it required water lowering, flowing mechanism
disassembling and assembling (only two part can be easily removed though),
and some physical (and indecent wording) "influence". Now I feel myself
much more comfortable in the apartments, although it is quite cold there,
at least without clothes at 6 A.M.
If things will stay in good direction, I plan to paint the whole ceiling this
week and then start to glue wallpapers and put floor covering.
Eventually I will start bathroom development...
/devel/flat :: Link / Comments (0)
A super quest.
What is it?

Answer can be found in gallery, starting from
this item,
but do not look there until your first answer is ready, I almost sure it was wrong,
but if you are that lucky, feel free to ask me for beer.
This super orange colour (better look in gallery) selected to specify sleeping area.
/devel/flat :: Link / Comments (0)
40 santimeters of snow in Moscow!
/other :: Link / Comments (0)
|