There was only one catch and that was Catch-22, which specified that a concern for one’s safety in the face of dangers that were real and immediate was the process of a rational mind. Orr was crazy and could be grounded. All he had to do was ask; and as soon as he did, he would no longer be crazy and would have to fly more missions. Orr would be crazy to fly more missions and sane if he didn’t, but if he was sane he had to fly them. If he flew them he was crazy and didn’t have to; but if he didn’t want to he was sane and had to. Yossarian was moved very deeply by the absolute simplicity of this clause of Catch-22 and let out a respectful whistle.

PAE really really sucks.

The biggest single reason to go 64-bit is exactly because of physical address space. Your virtual address space needs to bea multiple of the physical one: when you hit 1GB of RAM, 32-bit virtual memory is no longer acceptable. You literally do need more virtual memory than physical.

PAE turned that very simple fact on its head, and screwed things up royally. Whoever came up with the idea was totally incompetent, and had forgotten all the DOS HIGHMEM pains. There’s a damn good reason why we left the 286 behind, and started using 386’s, instead of having HIGHMEM crap with windows into a bigger physical space.

Repeat after me:

virtual space needs to be bigger than physical space. Not “as big”. Not “smaller”. It needs to be bigger, by a factor of at least two, and that’s quite frankly pushing it, and you’re much better off having a factor of ten or more.

Anybody who doesn’t get that is a moron. End of discussion.

Reasons for why you need a bigger virtual space:

- you need to map that physical memory somehow, and no, tiny windows into the physical memory simply do not cut it! If you cannot have normal pointers to the physical space, it immediately means that you need to jump through serious hoops to get there.

- you additionally need to be able to remap things in alternate ways (ie user space) or make space for non-memory issues (virtual page tables, IO, you name it)

Ergo, a factor-of-two is a requirement. PAE was a total and utter disaster.

Yes, Linux supported it, and probably did so better than anybody else. But “better than anybody else” still wasn’t very good. Because you couldn’t use normal pointers to point to arbitrary physical memory, all the memory that couldn’t be accessed directly (ie anythign that didn’t fit in the virtual address map, which also had the user space memory in it) was basically limited to “special uses only”.

So you could allocate user pages in it, but you had huge problems with things like internal kernel data structures, which can be the bulk of your memory needs under some (not that unusual) loads. Directory caches, inodes, etc couldn’t use it, and in general it meant that under Linux, if you had more than 4GB of physical memory, you generally ran into problems (since only 25% of memory was available for normal kernel stuff – the rest had to be addressed through small holes in the tiny virtual address space).

I’m not at all surprised that Windows didn’t push PAE either. It was a total braindamage. I bet they supported it in the server offerings just because they had to, and I bet they did a much worse job of it than Linux did, and the reason you can do that with servers is that the loads are much easier, and you can expect maintainers to set magic config entries to tweak it to make it appear to work well for any particular load, when in reality it is fragile as hell and works only with duct-tape and prayers.

That kind of “duct-tape and prayers and lots of specialized knowledge about the load” is simply not possible in a desktop environment. Yeah, users have prayers, but they lack the duct-tape and the knowledge to work around the problems.

And dammit, in this age and date when almost everybody has a gigabyte of RAM in any new machine, anybody who still thinks that “not that many people need 64-bits” is simply not aware of what he’s speaking of.

Go back and play with HIGHMEM.SYS on a 286, and stop blathering crap. When you’ve spent the last ten years of your life working with HIGHMEM.SYS, then you can come back and tell me that we still don’t need 64 bits. Until that is the case, anybody who still doesn’t get why 64 bits is a requirement should just shut up rather than make a total fool of himself.

So repeat after me: PAE didn’t ever really fix anything. It was a mistake. It was just a total failure, and the result of hw engineers not understanding software.

So no, PAE does not mean that you can use more than 4GB of RAM. Even before PAE, the practical limit was around 1GB, and PAE didn’t move that post a fraction of an inch!

Linus

НАЙ-ДОБРОТО ОТ ДРЪМ и БАС СЦЕНАТА КРАЙ КЪТИНА

Броени дни до края на промоционалните билети.

София, 28 април 2010г.

За десетото юбилейно издание на фестивала тази година, културните дейци от H.M.S.U. ще обогатят родната сцена с най-актуалното от дръм енд бейс музиката от изминалата година.

Мястото е отново китното Софийско селце – Кътина. И тази година ще има организирани охраняема парти зона, културни и спортни активности, място за къмпинг, добре подсигурен бар, безплатен паркинг и др. Към програмата на събитието ще бъдат прибавени още над 30 изпълнители от България и цял свят, музиката отново ще свири над 40 часа.

Потвърдиха участието на фестивала Noisia /Холандия/, безспорно най-популярните продуценти в момента, като холандците ще представят новият си албум, с който в момента предизвикват истински фурор. Разбира се освен тях, ще можете да чуете още и ветерана Nicky Blackmarket /Англия/ – собственик на най-големият магазин за плочи в Лондон, както любимецът на DJ Hype /Агнлия/ и машина за фънки днб бийтове – Hazard /Англия/. Лекция по селекция от мелодичен дръм енд бейс ще изнесе самият Big Bud /Англия/, докато мрачнaте страна на басса ще бъде поверена в ръцете на момчетата от С4С /Англия/ и The Sect /Англия/ .

Любопитен факт – на наградите за дръм енд бейс музика и култура провели се в Бирмингам, Noisia отнесоха наградата за “Най-добър днб продуцент”. Nicky Blackmarket беше избран за “Най-добър олд-скул селектор”, МC Eksman взе статуетката за “Най-добра лирика” сред майсторите на микрофона, а Hazard се нареди на престижното второ място в категория “Най-добър DJ”. Всичките те ще бъдат гости на фестивала край Кътина тази година.

За пореден път организаторите предоставят на публиката първокласно събитие на цена без аналог в Европа. Билетите са в продажба от 22-ри март на преференциална цена от 20лв. Тази цена ще се запази до края на април. От май цената е 30лв., а на вход – 40лв. Билетът само за втората вечер ще струва 30лв.

Билети могат да бъдат закупени в столичните магазини:

4:20 Shop (ул. Пиротска 61),
BreakPoint (ул. Гурко 72),
BreakPoint (Мол “The Boulevard” Младост 1A)
Dukan Meloman (ул. 6-ти Септември 7a),
Vision (бул. Мария Луиза 55),

online и за останалата част от света на

www.ticketpro.bg

Възрастово ограничение 18+

Айде пак на локалка!

HMSU prsnt:

ДРЪМ и БАС FILEz

hmsu ol’ skul selekta:

Cooh

/ Position Chrome, H.M.S.U. /

Ogonek

/ H.M.S.U., Metafiziq /

Konspirator

/ H.M.S.U. /

Mocks

/ H.M.S.U., T-Free /

Targy

/ H.M.S.U. /

acidtrip

/ H.M.S.U. /

EXo

/ H.M.S.U., Mirizma /

nu-skul beatz::

Solaris

/ Bassline-BG /

Smartech

/ Drumrollerz /

M@D TWIST

/ Metafiziq /

Bruhu

/ Camp Sessions /

Monotype

/ Dubplate Terra Digital /

Subzter

/ nextstation.org /

Broozy

/ nextstation.org /

entrance before 00:00:

8 BGN

entrance after 00:00:

10 BGN

start:
22:00h

end:
06:00h

Възрастово ограничение: 18+

It was recently noted that ioctl() system calls are still executed with the Big Kernel Lock (BKL) held. A suggestion was made that drivers which can implement ioctl() without the BKL held should be specially flagged as a way of increasing parallelism. That suggestion looks like it will not get very far. But it did pique your editor’s interest in current use of the BKL. Besides, there hasn’t been a whole lot else going on this week.

The BKL is an artifact from when the Linux kernel first supported multiprocessor systems. Making the kernel safe for concurrent access from multiple CPUs has been a multi-year task; it is not a job that could have been done all at once at the beginning. So Linux 2.0 supported SMP systems by way of the BKL, which only allowed one processor to be running kernel code at any given time. The BKL is essentially a spinlock, but with a couple of interesting properties:

• The BKL can be taken recursively; the kernel remembers how many times a given thread has called lock_kernel() and does the right thing. Normal spinlocks are rather less forgiving.
• Code holding the BKL can sleep. The lock is released while the given thread sleeps, and reacquired upon awakening.

The BKL made SMP Linux possible, but it didn’t scale very well. Its overhead could be felt even with two processors, and it made running on anything larger problematic. So the kernel developers have been breaking the BKL into finer-grained locks ever since. Thus, for example, the block I/O subsystem went from the BKL to its own lock (io_request_lock) in 2.2, and from that to individual queue locks in 2.6. The kernel now has thousands of locks, and some people had assumed that the BKL would be gone by 2.6.

As it turns out, there are still over 500 lock_kernel() calls in the 2.6.6 kernel. For the curious, here are some of the places which still rely on this old, system-wide lock:

• The core kernel retains a few calls. The implementation of the reboot() system call is one of them; this is, of course, not one of the more performance-sensitive parts of the kernel. The boot-time early initialization process is also run with the BKL held. The sysctl() system call is run under the BKL; interestingly, while much of /proc is also implemented under the BKL, it appears that reads and writes to /proc/sys do not run with the BKL held.
• Many older filesystems (UFS, coda, HPFS, FAT, NCP, SMB, Minix, etc.) make heavy use of the BKL for serialization. The UnixWare “Boot File System” implementation has several calls; somehow, they seem unlikely to be fixed anytime soon. There are also lock_kernel() calls in NFS, UDF, isofs, the reiserfs journaling code, autofs, and some others. The ext2 filesystem uses the BKL to protect modifications to the superblock; ext3, instead, had all of its lock_kernel() calls purged during the 2.5 development process.
• The rpciod kernel thread spends its entire life with the BKL held.
• Core dumps are created with the BKL held.
• Block and character devices have their open() methods called under the BKL. Block release() methods are also called this way, but that is not true for char drivers. The default llseek() method runs under the BKL, but, if a driver or filesystem provides its own llseek() method, that method will not be called with the BKL held. The fasync()  method is always called under the BKL. As noted at the beginning, ioctl() methods are called with the lock held; additionally, the ugly code which does 32-bit emulation on 64-bit systems needs the BKL.
• The file locking code still requires the BKL.
• Almost 10% of the lock_kernel() calls can be found in the (old, deprecated) OSS sound code. The ALSA code has no BKL calls, with one exception: the implementation of its /proc files.
• Most of the architectures retain some calls in the arch-specific code. The ptrace() system call is one common place for these calls. i386 also uses the BKL to protect llseek() calls on the CPUID and MSR pseudo-devices. uClinux performs execve()  calls under the BKL.
• Almost all of the remaining BKL calls are to be found in device drivers. The TTY subsystem still has quite a few of them, as does USB. Many of these calls are protecting llseek()  implementations. Quite a few of the rest are for the creation of special-purpose kernel threads: the daemonize() function needs to be called with the BKL held. Those calls can, presumably, go away as the driver code is (slowly) migrated over to the new kthread calls.

Given how poorly the BKL is viewed, it may be surprising that so many places in the kernel still use it. The simple fact is that, with regard to the BKL, all of the low-hanging fruit has long since been taken. For most of the remaining calls, removing the BKL is not worth the trouble and code churn. So, while removal of the remaining calls over the 2.7 development series looks entirely possible, it would not be surprising if that does not happen.

http://lwn.net/Articles/86859/

/*
* It would make sense to put struct rusage in the task_struct,
* except that would make the task_struct be *really big*.  After
* task_struct gets moved into malloc’ed memory, it would
* make sense to do this.  It will make moving the rest of the information
* a lot simpler!  (Which we’re not doing right now because we’re not
* measuring them yet).
*
* When sampling multiple threads for RUSAGE_SELF, under SMP we might have
* races with threads incrementing their own counters.  But since word
* reads are atomic, we either get new values or old values and we don’t
* care which for the sums.  We always take the siglock to protect reading
* the c* fields from p->signal from races with exit.c updating those
* fields when reaping, so a sample either gets all the additions of a
* given child after it’s reaped, or none so this sample is before reaping.
*
* Locking:
* We need to take the siglock for CHILDEREN, SELF and BOTH
* for  the cases current multithreaded, non-current single threaded
* non-current multithreaded.  Thread traversal is now safe with
* the siglock held.
* Strictly speaking, we donot need to take the siglock if we are current and
* single threaded,  as no one else can take our signal_struct away, no one
* else can  reap the  children to update signal->c* counters, and no one else
* can race with the signal-> fields. If we do not take any lock, the
* signal-> fields could be read out of order while another thread was just
* exiting. So we should  place a read memory barrier when we avoid the lock.
* On the writer side,  write memory barrier is implied in  __exit_signal
* as __exit_signal releases  the siglock spinlock after updating the signal->
* fields. But we don’t do this yet to keep things simple.
*
*/

Cooh
/ Position Chrome, H.M.S.U. :: Bulgaria /

Mocks
/ H.M.S.U. :: Bulgaria /

Konspirator
/ H.M.S.U. :: Bulgaria /

Targy
/ H.M.S.U. :: Bulgaria /

acidtrip
/ H.M.S.U. :: Bulgaria /

EXo
/ H.M.S.U. :: Bulgaria /

visuals by kmn / blender.cult.bg

entrance before 00:00:
6 BGN

entrance after 00:00:
8 BGN

start:
23:00h

end:
06:00h

!!! ALL YOUNG TALENT IS WELCOME TO TRY THEIR AUTHOR TRACKS BEFORE THE EVENT – STARTING 20:00

Събитието ще се проведе в най-голямата – Бяла Зала!

party dress code
white media-popular head masks :)

hmsu room:

Cooh

/ Position Chrome, H.M.S.U. :: Bulgaria /

Ogonek

/ Metafiziq, H.M.S.U. :: Bulgaria /

Mocks

/ H.M.S.U. :: Bulgaria /

Konspirator

/ H.M.S.U. :: Bulgaria /

Targy

/ H.M.S.U. :: Bulgaria /

acidtrip

/ H.M.S.U. :: Bulgaria /

EXo

/ H.M.S.U. :: Bulgaria /

visuals by kmn / blender.cult.bg

nu blood room:

Thought

/ Tech Itch, Freak :: Bulgaria /

Digital Soul

/ Metafiziq, Wayside, HMSU.net :: Bulgaria /

Broozy

/ Nextstation :: Bulgaria /

Charoday

/ Chronic Vibez :: Bulgaria /

Subzter

/ Bulgaria /

Yango

/ Bulgaria /

entrance before 00:00:
8 BGN

entrance after 00:00:
10 BGN

start:
22:30h

end:
06:00h

!!! ALL YOUNG TALENT IS WELCOME TO TRY THEIR AUTHOR TRACKS BEFORE THE EVENT – STARTING 21:00

Програмистът Линус Торвалдс, който преди около 18 години инициира създаването на операционната система Linux, определи сегашния вид на Linux – ядрото като “раздуто и огормно”. Това стана по време на кръгла маса, в рамките на конференцията LinuxCon в САЩ.

Модераторът на дискусията – Джеймс Ботъмли от компанията Novell – цитира вътрешно изследване на Intel, според което производителността на Linux пада с два процента с всеки нов релийз. Така общото понижение на производителността за последните десет релийза е достигнало 12 процента.

Според Торвалдс, версия 2.6.31 на Linux – ядрото силно се различава от бързата и компактна версия 0.01, която той е написал преди 18 години. Нещо повече – той изрази убеждението си, че днес обществото, подкрепящо тази операционна система не разполага с план за промяна на ситуацията.

Все пак легендарният програмист е останал доволен от стабилността на текущата версия на Linux – ядрото, както и от бързината, с която разработчиците се справят с откритите в системата грешки.

източник: linux-bg.org

August 22, 2009

Varna, Seagarden Casino /big hall/

11:30 – 00:30 – EXo (dubstep & jungle / HMSU, Mirizma)
00:30 – 01:30 – acidtrip (jungle & dubrock, / HMSU )
01:30 – 02:30 – Mocks (techstep & classics / HMSU, T-Free )
02:30 – 03:30 – COOH (hard style & digital hardcore / HMSU, Offkey)
03:30 – 04:30 – Ogonek (technoid / HMSU, Metafiziq)
04:30 – 05:30 – Targy (techstep / HMSU)
05:30 – 06:30 – Konspirator (jump up & wobble / HMSU)

WORKSHOPS:

16.00 – 16.30 :: First steps with the Skyrunner (with Misho)
16.30 – 17.15 :: Basic mixing concepts (with Konspirator)
17.30 – 18.00 :: How do I release my tracks? (with Ogonek + CoоH)
18.15 – 19.00 :: Getting to know some important DNB labels (with Тарги)
19.15 – 20.00 :: Intro to generative arts ( with ЕХо )