|
|
About
TODO
Blog
RSS
Old blog
Projects
Gallery
Notes
Mon, 26 Feb 2007
Dillon's Infinitely Snapshotable And Segmented Transactional Exabyte Repository. [ND]
Excellent!
That is about upcoming DragonflyBSD filesystem.
After I read its design in details, I can only say
that it is not a design, but some very initial draft,
so it is early to discuss even ideas.
What rises a question for me is its segmentation.
Storage is divided into segments, each one has some
special header to indentify inner blocks, segments can
be transformed inot bigger and smaller ones. (one problem I see right
now is its indexing, which is 16bits only, while segment size
is 4Gb maximum, so we end up with 48-bits addressing mode only).
Interesting ideas, which I plan in my FS too are unlimited
snapshotting and absence of log structure to store history of file changes.
I also plan to replicate suberblock (as all fs should do anyway),
which was not highlighted in Dillon's paper. I also plan to have
plugin layer (which should be able to be turned off to not
show a red flag for Linux FS developers) and likely unified cache
for directory entries, inodes and pages.
/devel/fs :: Link / Comments (0)
Merde, I've missed climbing training due to endless (and actually empty) discussions.
I'm absolutely sure Ingo will not agree with me (and I even
do not say about Linus), so what is the point?
Ingo said - 'fuck kevents', Linus will listen to him - things
will be closed in private ring like usual, why do I ever continue?
And I finished bottle of wine (Krimsk's 'Tamansky Heres' - quite tasty thing).
Update: hmm, there is even a (somehow far, but nevertheless) positive moment that they decided to drop kevent -
I have plenty of time for other interesting ones. I just would like they to say
me that half of a year ago and did not fuck my brain, but from other point of view I got a lot
of interesting challenges and support, which is an award by itself :)
/life :: Link / Comments (0)
Kevent vs. epoll vs. threadlet on VIA EPIA.
Small machine (256 mb of ram, 1Ghz):
kevent: 849.72
epoll: 538.16
threadlet:
# gcc ./evserver_epoll_threadlet.c -o ./evserver_epoll_threadlet
In file included from ./evserver_epoll_threadlet.c:30:
./threadlet.h: In function threadlet_exec:
./threadlet.h:46: error: can't find a register in class GENERAL_REGS while reloading asm
That particular threadlet asm optimization does not work.
/devel/kevent :: Link / Comments (0)
How to get attention to your project (secret plans upto now). Kevent and Ingo's threadlets. Scholastic masturbation about events and execution context. [ND]
As you might noticed, kevent was not a favour up to date, it is quite a good subsystem, but
no attention. So, steps to get an it.
AIO is a hot topic this days - mainly because of Zach Brown's
efforts to create generic AIO subsystem suitable for database usage
on top of micro-thread design (blessed by Linus Torvalds some time ago).
As you have noticed from this blog, I'm against such a step, so I started
to participate in related threads.
Eventually Ingo Molnar implemented own micro-thread AIO design - it has the same
generic disadvantages as all other micro-thread implementations from Zach and Linus,
but since Ingo is a scheduler-god, he has some tricks (shit, I would
look into a dictionary to check how part of the wear, which starts near the shoulder
and covers the arm is called, but since it is time to work without dictionary (and admin
at my paid work fucked my (hacked a bit due to bugs in firewall setup and social engineering)
connection down to frequently miserable bytes/per second)),
well, Ingo has some tricks for x86 which allows to create extremely high-performance
kernel threads on x86.
So, kevent is in danger - one of its users - mainly kevent AIO, created as
a pure state machine over some VFS bits and network items, kevent AIO can be
replaced with micro-thread (ugly) design.
I started some participation (mainly in blog) in related threads, so eventually,
when first syslet patch was created, I was in Cc list and started to analyze
patchset (both in blog without political correctness, and in mail lists with one).
Now we have following things:
- Ingo-scheduler-god is for his threadlet/syslet model, but agree, that kevents can be superior
in some aspects.
- Linus-linux-god is against me at all, mainly because we are doing purely theoretical
even scholastic masturbation about events vs. execution context (read his mail to David Miller,
where he argues that it is idiotic to think about network as AIO model, I will return to that item soon,
it is too fun to talk with Linus using his words).
As you can see, Linus and Ingo (and a lot of other hackers) talk about kevent and events vs. context
in general. It is good and interesting even not because kevent is discussed.
And it is challenging!
Heh, things has ended up with complete fight against kevent.
Ingo Molnar wrote:
conclusion: currently i dont see a compelling need for the kevents
subsystem. epoll is a pretty nice API and it covers most of the event
sources and nicely builds upon our existing poll() infrastructure.
I need to say, that I have not ran any tests yet, since my Intel Core2 test machine
has x86_64 distro, and I can not download new distro du to bandwidth limitation, and
my via epia machine still compiles a tree...
So, right now I'm cooking up a tree which includes both kevent and syslet/threadlet
patches to test kevent/epoll/threadlet. I will do it on couple of my test machines:
via epia (1ghz, 256mb of ram, 100mbit ethernet) and Intel Core2 CPU (2.40GHz, 2gb of ram,
gigabit ethernet). Client will be 'ab' on my desktop Intel Core Duo 3.7 Ghz
test machine with gigabit ethernet.
So, stay tuned - if I will complete all setup before I go climbing (and wine will not end),
I will post all results here (even if kevent will shitassly suck).
Meanwhile on x86_64 several runs of the same
ab -c8000 -n80000 http://192.168.0.48/
kevent 8447.78
5248.45
4792.66
4689.78
4978.08
5207.60
epoll 4572.20
5024.89
4580.57
4800.19
4708.29
Even in median kevent is faster than epoll.
And some times it is about two times faster.
/devel/kevent :: Link / Comments (0)
Debian sucks! [ND].
I'm using debian testing on all my test machines and desktop.
Debian testing (further Etch) sucks (shit, I'm selecting a word (but fail without english dictionary,
if you would know russian, I can provide a real poem of how it is broken) which would
express the whole universe in a couple of letters, and also all my mood in the regard of regualr crashes
of gnome-terminal and Iceweasel, but I can not send bug report, since I can not reproduce
that problem on demand in debugger). Fedora did not allow such bugs, although its X server ate my memory.
Crap. And bottle of the wine (I got a bottle of 'Heres') is almost over.
And I'm going climbing at 5-30 o'clock.
/devel/other :: Link / Comments (0)
|