About :: TODO :: Blog :: RSS :: Old blog :: Projects :: GIT :: Gallery :: Notes

Sat, 03 Feb 2007

Jokes from weather center in Belarus.


There is an official site of belarusian weather center. Here are screeenshots of what can be found when pointing cursor to the Bobruysk weather 'records'.

This one from life and political news from idiot.ru:


This one I got today myself:

/other :: Link / Comments ()

New acrypto release for 2.6.20 kernel.


Acrypto allows to handle crypto requests asynchronously in hardware.

Acrypto supports following features:

• multiple asynchronous crypto device queues
• crypto session routing (allows to complete single crypto session when several operations (crypto, hmac, anything) are completed)
• crypto session binding (bind crypto processing to specified device)
• modular load balancing (one can created load balancer which will get into account for example pid of the calling process)
• crypto session batching genetically implemented by design (acrypto provides the whole data structure to crypto device, i.e. it is possible to use acrypto as a bridge which routes requests between completely different devices, since it does not differentiate between users, just handles requests)
• crypto session priority
• different kinds of crypto operation(RNG, asymmetrical crypto, HMAC and any other)

• acrypto core
• IPsec ESP4 port to acrypto
• dm-crypt port to acrypto
• OCF to acrypto bridge, which allows to run OCF device drivers with acrypto (for example ixp4xx), requires OCF installed.

• removed class device usage (Spotted by Markus Kammerst)
• port to 2.6.20 tree

• extend software provider to support all types of ciphers

/devel/acrypto :: Link / Comments ()

New HIFN 795x crypto accelerator driver release.


It includes API changes related to mainline work struct update and changes related to acryto naming (by Markus Kammerst).

New version available from acrypto homepage.

/devel/acrypto :: Link / Comments ()

Fibrills and threads.


Let me briefly describe how I understood Ingo Molnar (and his idea of having set of working threads, each of which works with caches of requests, which form state machine of given AIO operation), Linus Torvlads and Zach Brown (who invented fibrils - small process stacks which are created for each AIO call and scheduled when operation blocks).

Main Zach's idea is to clone (create a limited clone actually) current process' stack and issue a call in it, so essentially he creates a new lightweight thread per AIO call. That thread is called fibrill, it is limited in that regard, that it is strictly bound to the executing process, thus it is not allowed to schedule fibrill while main process is not running. It is exactly userspace threads, described here, but without SMP scalability, and in kernelspace.
So, when AIO call is performed, special stack is allocated on behalf of calling process, and that stack works like micro-thread, which can sleep, can be scheduled away (and main process will continue its execution right after the call), can be awakened and so on. Main disadvantages are impossibility to scale on SMP since fibrill is bound to process, it is not real thread, per syscall stack allocation (which is quite heavy, about 1.5k) and initialization, and rescheduling cost (consider thousands of pending AIO calls, each of which is a small thread).

Another approach was invented by Ingo Molnar and implemented in his Tux in-kernel http/ftp server and in kevent AIO (although I though about it independently, but did look into Tux code later).
This approach embedds limited set of real working threads, say 10 or 2 or 64, per process (in kevent it is global limit), which execute operation requests, each of which form some state machine, for example async sendfile consists of file opening (name lookup), sending its data (which in turn consists of populating data into VFS cache and actual sending over the network) and file closing. Such a cache (in kevent notation it is also called a 'request') of functions, which form a state machine, is executed on one of the real threads until some operation is blocked, so when it happens, another threads can start executing its requests, so such approach scales well on SMP.
Main disadvantage is complexity of state machine programming, but it is quite doable, which is shown in kevent AIO and Tux.

So, for kevent, I've put into TODO list to extend it to create set of threads on behalf of each process, issued AIO request (instead of having global threads), and spread work between them without blocking of the main process. It would look like implicit creation of several threads using clone() syscall, so that all threads would have the same process ID and would obey to process' rlimits.

/devel/kevent :: Link / Comments ()

Fibrills AIO, kevent AIO and Ingo's ideas.


Are you fucking kidding?
It does exist in kevents already.
Everything.
From the beginning to the end.
Completely.

I sometimes feel that kevent mails are not even read by anybody, but at least for now I thought that only diff itself was not read (I specially put couple of fancy printks in the code, which were only noticed by Jonathan Corbert in LWN), but at least annotations were.
Now it looks like they were not too.

And another one.

What is really good in that discussion, is the fact, that kevent AIO should have pool of threads per process, not globally. That will solve any rlimit problems and allows to scale to any number of processes issued AIO calls. In that regard kevent is limited, since number of working threads does not scale with number of processes started AIO work.

/devel/kevent :: Link / Comments ()