The Mill CPU architecture videos.

https://millcomputing.com/docs/

Ivan Godard talks on different aspects of the Mill CPU family architecture. The Mill CPU family is an attempt to develop a new high performing architecture with high ILP(instruction level parallelism) on the principles different from mainstream CPU design practice. The real treasure is Ivan Godard's ability to introduce the current state of the field in concise form and then seamlessly move to the Mill architecture that uses a new approach.

Dr Onur Mutlu's Lecture and Videos

 Probably the most comprehensive online course on computer architecture.

https://users.ece.cmu.edu/~omutlu/lecture-videos.html

The Journal of Instruction-Level Parallelism

Looks like the Journal is defunct but nevertheless worth browsing

http://www.jilp.org/

CS150 Components and Design Techniques for Digital Systems

http://www-inst.eecs.berkeley.edu/~cs150

Landauer's eraser

 In 1961 Landauer showed "that the erasure of one bit of information is necessarily accompanied by the release of at least kTln(2) of heat into the environment" this defines the theoretical minimum for energy consumed by a system with memory which is W = kT ln(2) for each bit of a state, where k is a Boltzmann constant and T is a system temperature. This principle helped to solve the paradox of Maxwell's Demon.

  The following articles are a good source of reference

 "The physics of forgetting: Landauer’s erasure principle and information theory" - http://www3.imperial.ac.uk/pls/portallive/docs/1/55905.PDF

Information: From Maxwell’s demon to Landauer’s eraser - http://scitation.aip.org/content/aip/magazine/physicstoday/article/68/9/10.1063/PT.3.2912

Unsafe use of FltGetFileNameInformationUnsafe

  FltGetFileNameInformationUnsafe name is spot on. It is very unsafe and dangerous function but not in the way mentioned in WDK. The documentation misses yet another dangerous case when it should not be used. This case is related to file system isolation filters( for more information on such filters follow this link https://www.osronline.com/article.cfm?article=560 ). I would state this additional condition as

  - A filter driver must not use FltGetFileNameInformationUnsafe for file objects it never observed. A filter observed a file object if it was called at least once with this file object for any operation and it never received IRP_MJ_CLOSE for this file object or observed a failed IRP_MJ_CREATE. This condition guaranties that a file object is initialized by a filter of file system driver that is beneath a filter calling FltGetFileNameInformationUnsafe . 

  When the above condition is violated by any file system filter a filter might call an underlying file system with a file object this file system never initialized as the file object was initialized by a file system filter that is above a filter that has called FltGetFileNameInformationUnsafe . At first glance it seems that in that case an upper filter must isolate the underlying filters from such file object. This is true, but there is a degenerate case when a filter can gain access to file objects that it should never see. This is a case of a process creation callback when a file object for executable file is provided as a parameter to a callback and this file object might have been initialized by a file system filter above one that registered this callback. Below is a call stack from the system where Microsoft Windows Defender file system minifilter used FltGetFileNameInformationUnsafe from a process creation callback to query a file name for a file object initialized by a file system filter attached to MiniFilter Manager ( aka fltmgr.sys ). 

Ntfs!NtfsCommonQueryInformation+0xa7

Ntfs!NtfsFsdDispatchSwitch+0xd3

Ntfs!NtfsFsdDispatchWait+0x47

nt!IovCallDriver+0x3cd

fltmgr!FltpQueryInformationFile+0x10e

fltmgr!QueryStandardLinkInformation+0x4d

fltmgr!FltpSetStreamListStandardInformationFlags+0x7a

fltmgr!FltpGetFileNameInformation+0x796

fltmgr!FltGetFileNameInformationUnsafe+0x71

WdFilter!MpGetImageNormalizedName+0x51

WdFilter!MpCreateProcessNotifyRoutineEx+0x77

nt!PspInsertThread+0x7a7

nt!NtCreateUserProcess+0x806

nt!KiSystemServiceCopyEnd+0x13

As a result NTFS crashed when it received an IRP with a file object initialized by a file system filter attached to the top of the drivers stack. The obvious solution is to use the old good ObQueryNameString as it has been done for the last 25 years by the kernel itself, for example in NtQueryVirtualMemory when processing a memory region supported by a mapped file. In that case an IRP is created and sent from the very top of a drivers stack so an isolation filter has a chance to intercept this IRP and complete it.

On interrupts handling by a kernel

This is an excerpt from Jonathan S. Shapiro's article "Design Note: Kernel Interrupt and Concurrency Management" 

With the exception of the interval timer interrupt and (on SMP systems) the interprocessor interrupt, Coyotos does not handle interrupts directly. Also, the kernel does not support interrupt nesting. Our working assumptions are:

• The longest kernel path is very short (units of microseconds).
• We can therefore defer doing anything about interrupts until we are just about to exit the kernel, when kernel state is not ``in flight.''
• Since we are going to defer interrupt handling to the scheduler, the kernel does not need to deal with nested interrupts.
• It is preferable, and not much unduly expensive, to prioritize interrupt handlers using the kernel scheduler rather than hardware priorities.
• If it were not for the need to deal with the interval timer interrupt and IPI issues, we could hypothetically run with interrupts entirely disabled in the kernel.

Ignoring the interval timer and the interprocessor interrupt, the primary action taken by the kernel in response to an interrupt is to wake up the relevant driver process by moving it from a per-interrupt stall queue to the ready queue. A preemption occurs only if the awakened process is higher priority than the currently executing process. On hardware platforms where a prompt hardware-level acknowledge is required to avoid interrupt controller lockup, the interrupt handler takes care of this as well.