linux

That commit is correct (4c48abe91be03d191d0c20cc755877da2cb35622), but it was not in 4.12 as cut by linus. https://github.com/torvalds/linux/commit/4c48abe91be03d191d0... (click the little '...' to expand tags it's in) or: $ git tag --contains 4c48abe91be03d191d0c20cc755877da2cb35622 v4.13 What is your methodology that gets that it is in the 4.12 tree?

cryptsetup benchmark --cipher aes-xts # Tests are approximate using memory only (no storage IO). # Algorithm | Key | Encryption | Decryption aes-xts 256b 2266.2 MiB/s 2273.8 MiB/s perf says 21.86% cryptsetup [aesni_intel] [k] _aesni_dec4 19.83% cryptsetup [aesni_intel] [k] _aesni_enc4 17.80% cryptsetup [aesni_intel] [k] aesni_xts_crypt8 13.73% cryptsetup [kernel] [k] copy_user_generic_unrolled 2.20% cryptsetup [kernel] [k] get_page_from_freelist 1.86% cryptsetup [glue_helper] [k] glue_xts_crypt_128bit 1.53% cryptsetup [kernel] [k] put_page 1.36% cryptsetup [k

This kernel model was written for the explicit purpose of modifying the BIOS[1]. The module writer makes the recommendation of not enabling in KConfig[2]. The question is did Ubuntu enable it by default and if so, why? [1] https://github.com/torvalds/linux/blob/master/Documentation/... [2] https://github.com/torvalds/linux/blob/8afda8b26d01ee26a60ef...

The kernel has a clear definition of what will be backwards compatible, and what never will be. In-kernel interfaces are never stable, and kernel-to-userspace interfaces are very stable, with an ABI docs directory breaking out what is and isn't. https://github.com/torvalds/linux/blob/e7aa8c2eb11ba69b1b690... If the kernel's user interface just started blocking on open for 4000 milliseconds for no apparent reason, people would not be happy. Firefox expects users to demand that app writers edit, recompile, test, and ship them a new app to prevent the block. This is <insert lots of not very nice adjectives>.

I've had a really bad run-in with transparent hugepage defragmentation. In a workload consisting of many small-ish reductions, my programme spent over 80% of its total running time in pageblock_pfn_to_page (this was on a 4.4 kernel, https://github.com/torvalds/linux/blob/v4.4/mm/compaction.c#...) and a total of 97% of the total time in hugepage compaction kernel code. Disabling hugepage defrag with echo never > /sys/kernel/mm/transparent_hugepage/defrag lead to an instant 30x performance improvement. There's been some work to improve performance (e.g. https://github.com/torvalds/linux/commit/7cf91a98e607c2f935d... in 4.6) but I haven't tried if this fixes my workload.

> It's possible some hardware already does overlays, given that the talk I linked above was 2 years ago. I haven't researched this carefully. All hardware does some overlays, though not a large number. (You can see Intel GPU overlay setup at [1].) One scanout overlay is already in use on all major OS's, to draw the mouse cursor. [1]: https://github.com/torvalds/linux/blob/e60e1ee60630cafef5e43...

Source for those interested: https://github.com/torvalds/linux/blob/master/lib/refcount.c I'm kind of surprised that the authors went with compare-and-exchange for their ref count, rather than get-and-increment. Even if the counter does overflow, it's usually detectable, and reversible. This is true even in the face of concurrent updates. The benefit is that there is only one atomic operation in the fast path.

The browser internals aren't userspace. Web Extensions are userspace. The browser internals are more like kernel space, which the Linux kernel breaks, all the time [1]. [1]: https://github.com/torvalds/linux/blob/e7aa8c2eb11ba69b1b690...

This is based on a cursory examination of [1], so I may be off-base. But Xen appears to rely on the host for many things that can be, and often are, hardware accelerated in KVM. Searching for CONFIG_XEN_PVHVM, it doesn't appear to cover much. [1] https://github.com/torvalds/linux/blob/master/arch/x86/xen/

I've found file: unaligned-memory-access.txt useful. Ref:- Linux Kernel Source: UNALIGNED MEMORY ACCESSES Link: https://github.com/torvalds/linux/blob/master/Documentation/...

That's been experimental for a long time - https://github.com/torvalds/linux/tree/master/fs/9p I guess file systems don't go into staging/?

Here you go: https://github.com/torvalds/linux/commit/692b48258dda7c302e7... I do understand what you're saying though but I don't think people are going to just search Github for your name on the off-chance that you're on there, I suspect that what most people do is look at the things that you've specifically mentioned in your CV.

>; what about developers who refuse to use the email-based process? I guess I don't understand your question. In Linux, the email-as-the-workflow[1] has been agreed upon from Linux Torvald and his lieutenants all the way down. I suppose that if a one refused to use email-based-workflow, they'd have to find a Linux kernel maintainer to be a champion for their proposed changes and submit them on their behalf. (Is this a common scenario? I don't know.) If a rebel Linux kernel programmer insisted on staging changes for review in Gerritt/JIRA/github/etc, he's going to be isolated in an island because he's not part of the agreed-upon workflow: emails. [1] https://github.com/torvalds/linux/blob/master/Documentation/...

>> And your point doesn't always hold true. For example https://github.com/torvalds/linux/pull/17 > I don't know what this is supposed to mean What I linked to is an example of a discussion that didn't stay focused or tight despite the fact that it's not threaded.