andikleen2

6 ms·

1.
by andikleen2 18d ago
It's usually custom scripts, I'm not aware of a standard tool. You fill up the file system and then do lots of operations that cause fragmentation. Actually here is a recent paper discussing this (although the basic concept is muc
2.
by andikleen2 19d ago
Such tools really exist and they're used for testing file systems, so that you have a more realistic "aged" layout on a freshly created test file systems. We also have memory fragmenters to do the same for memory for the sam
3.
by andikleen2 3mo ago
Dave Jones used to have a series of "Why user space sucks" Linux kernel conference talks with many such examples, usually with dumb and redundant system calls. However as someone who looks a lot at instruction traces I could proba
4.
by andikleen2 9mo ago
Early x86-64 Linux had a similar problem. The x86-64 ABI uses registers for the first 6 arguments. To support variable number of arguments (like printf) requires passing the number of arguments in an extra register (RAX), so that the callee
5.
by andikleen2 1y ago
If you read Anderson "A history of Aerodynamics" it disagrees on this point. It states that the Wright's didn't have a good way to calculate drag, and they didn't understand many of the side effects from real wings
6.
by andikleen2 1y ago
> 4. First design that used a wind tunnel to get an efficient wing shape The Wrights based their wing on Lilienthal's who used a variant of a wind tunnel (as well as actual gliders) for optimizations. You could also argue he ran a c
7.
by andikleen2 1y ago
This technique works with any instruction that clobbers a register, not just with CPUID. In the worst case you could just single step the other CPUs until you hit an instruction that overwrites a register too. These are common. In my case (
8.
by andikleen2 3y ago
Having spent a lot of time porting 32bit system code to 64bit, I developed a dislike for these explicit types. It's a slippery slope to hard code your bitness with people making assumptions where size_t or pointers fit. Now maybe if yo
9.
by andikleen2 4y ago
Back when Usenet was still functional, de.sci.history (German history group) had some dedicated proponents of a German conspiracy theory that the early middle ages (Carolingian dynasty in middle Europe) didn't exist. Basically their ar
10.
by andikleen2 5y ago
Even if they don't livelock retries can be significantly slower than a direct atomic operation under contention. Compare https://www.cs.tau.ac.il/~mad/publications/ppopp2013-x86queu... Programming under high
11.
by andikleen2 6y ago
>Put simply, TSX is not mainstream, and isn't on track to be mainstream anytime soon. Being in the vast majority of servers deployed in the last decade (Intel+POWER) is not mainstream?
12.
by andikleen2 6y ago
Yes it totally is. How much confidence do you have in your lockless code?
13.
by andikleen2 6y ago
>essentially no cost unless the lock is contested. Atomics are not free. And fetching a cache line can be very expensive, even without contention. However lock less algorithms are often worse because they have even more atomics and even
14.
by andikleen2 6y ago
In the early tens we ran an engineering project to improve critical sections in applications using transactional memory. We had a PhD level intern applying our techniques to various open source projects. One target was MongoDB. After a few
15.
by andikleen2 6y ago
Seems trivial to exploit the kernel module: struct network_activity * activity = NLMSG_DATA(nlh); <untrusted data from the netlink socket> append_rule(activity->process_path, (activity->allowed == 1)); ... append_rule: &#
16.
by andikleen2 6y ago
Small mistake in the article. System V code was never released publicly by SCO, just some earlier variants not too far removed from V7. They make great code reading if anyone is interested. The early Unix variants were quite simple and conc
17.
by andikleen2 6y ago
You have to be a bit careful with the CLFLUSH method. I tried to use it in a widely used program years ago because Intel recommended it, but we found that it just hangs the CPU on some older VIA/Centaur CPUs. Presumably that's fix
18.
by andikleen2 10y ago
Yes with a read primitive it could be done in theory. It will be just quite awkward to use however as every caller has to do all that: define a lock, pass it always in, make sure the check for "lock is free" is correct etc. Your u
19.
by andikleen2 10y ago
This would be only useful for "good" page faults that fault something in, but not for "bad" ones (like NULL pointer). If a bad page fault was executed it would allow transactions to crash the program, which wouldn't
20.
by andikleen2 10y ago
Practically all valid fallback schemes require putting the lock (or something else like a sequence counter for a STM) into the read set of the transaction to properly synchronize between transactions and non transactions. Since you hide the
21.
by andikleen2 10y ago
He's assuming that retrying forever is a valid retry strategy, which it is not. For example if a page fault was needed to satisfy one of the memory access it would never finish. See https://software.intel.com/en-us&#x2F