朴泊斋

1. sudo apt-get install libasound2-plugins padevchooser libsdl1.2debian-pulseaudio

2. sudo apt-get remove --purge libflashsupport flashplugin-nonfree-extrasound

3. Open volume control, click preferences, and remember to check capture and microphone capture

4. Open skype options->sound devices, all choose pulse

 

Replace $Fontpath and $Font with your own path to the font and font's file

1. Copy $Fontpath/$Font to ~/.google/picasa/3.0/drive_c/windows/fonts/

2. Modify  ~/.google/picasa/3.0/system.reg

[Software\\Microsoft\\Windows NT\\CurrentVersion\\FontLink\\SystemLink] 1244379381
"Tahoma"=str(7):"$Font"

http://www.cs.nmsu.edu/~pfeiffer/classes/573/notes/ipt.html

First, remember basic TLB idea: cache of virtual memory translations. Absolutely vital for performance! The majority of TLB implementations are completely in hardware; they are managed just like a very small cache. However, given a little bit of size to the TLB, its hit rate will be much higher than the cache hit rate. This implies that we can manage the TLB in software; Alpha does this.

As address spaces get bigger, page tables get more unwieldy. 64-bit address might imply something like 5 levels of table (10 bit index for all but last). As virtual address spaces grow so much bigger than physical addresses, it becomes possible that we can save space and time by inverting the page table -- mapping physical to virtual, instead of the other way 'round.

So, instead of each process having a page table, and the page table entries mapping virtual addresses to physical addresses, we can have a single inverted page table for the system, which the entries mapping physical frames to (process ID, virtual page number) pairs. But, this requires very efficient search strategies! It can be done by hashing, and using a hash anchor table to map hashed virtual addresses to entries in the inverted page table. Then, each inverted PTE has to contain:

• The process ID of the owning process.
• The virtual page number.
• A pointer to the next IPTE in the hash chain.
• The normal protection, valid, modified bits referenced.

Here's a picture of the scheme.

The steps in a translation are:

1. Hash the process ID and virtual page number to get an index into the HAT.
2. Look up a Physical Frame Number in the HAT.
3. Look at the inverted page table entry, to see if it is the right process ID and virtual page number. If it is, you're done.
4. If the PID or VPN does not match, follow the pointer to the next link in the hash chain. Again, if you get a match then you're done; if you don't, then you continue. Eventually, you will either get a match or you will find a pointer that is marked invalid. If you get a match, then you've got the translation; if you get the invalid pointer, then you have a miss.

The surprising thing is that this can be reasonably efficient. If you can have a successful search in only a couple of probes on average, then fewer accesses are needed than to do a lookup in a page table that is more than a couple of levels deep.

Sharing memory between processes is problematic, to say the least.

http://www.eecg.toronto.edu/~tamda/papers/threadclustering.pdf

1. Monitoring Stall Breakdown: Using HPCs, CPU stall cycles are broken down and charged to different microprocessor components to determine whethercross-chip communication is performance limiting. If this is the case, then the second phase is entered.

2. Detecting Sharing Patterns: The sharing pattern between threads is tracked by using the data sampling features of the hardware PMU. For each thread, a summary vector, called shMap, is created that provides a signature of data regions accessed by the thread that resulted in cross-chip communication.

3. Thread Clustering: Once sufficient data samples are collected, the shMaps are analyzed. If threads have a high degree of data sharing then they will have similar shMaps and as a result, they will be placed into the same cluster.

4. Thread Migration: The OS scheduler attempts to migrate threads so that threads of the same cluster are as close together as possible.

http://www.northco.net/chenke/project/linux.html

User-Level Threads
User-level threads avoid the kernel entirely and manages the tables itself. User-level threads employ what is oftentimes called "cooperative multitasking" where the task defines a set of routines that get "switched to" by manipulating the stack pointer. The big advantage of user-level threads is they can switch faster than kernel level threads.

One of the main disadvantages is that user-level threads have a problem that a single thread can monopolize the time slice, creating starvation among other threads within the tast. Also, user-level threads have no way of taking advantage of Symmetric MultiProcessor systems like a dual-pentium. Last, when a thread becomes I/O blocked, all other threads within the tast lose the timeslice as well.

Some user-thread libraries have provided solutions to these problems with work-arounds. Timeslice monopolization was addressed by controlling it with an external monitor that uses its own clock tick. I/O blocking can be solved by creating special wrappers over system calls or the task can be written for nonblocking I/O.

Kernel-Level Threads
Kernel-level threads are implemented in the kernel using several tables (each task getting a table of threads). The kernel schedules each thread within the timeslice of each process. There is more overhead with switching in kernel-level threads but Linux's kernel-level threads perform nearly as well as user-level.

Linux can operate by using either entirely user-level or entierly kernel-level threads or a combination of both. Advantages for using kernel-level threads is that it's less likely for a thread to monopolize a timeslice. Also, I/O blocking is not a problem. If properly coded, the process can automatically take advantage of SMPs as well and will runn incremently faster with each CPU added.

http://en.wikipedia.org/wiki/Lottery_Scheduling

Lottery Scheduling is a probabilistic scheduling algorithm for processes in an operating system. Processes are each assigned some number of lottery tickets, and the scheduler draws a random ticket to select the next process. The distribution of tickets need not be uniform; granting a process more tickets provides it a relative higher chance of selection. This technique can be used to approximate other scheduling algorithms, such as Shortest job next and Fair-share scheduling.

近似保证了每个process都能分到公平份额的cpu cycle

Lottery scheduling solves the problem of starvation. Giving each process at least one lottery ticket guarantees that it has non-zero probability of being selected at each scheduling operation.

From ULK

In multiprocessor systems, semaphores are not always the best solution to the synchronization problems. Some kernel data structures should be protected from being concurrently accessed by kernel control paths that run on different CPUs. In this case, if the time required to update the data structure is short, a semaphore could be very inefficient. To check a semaphore, the kernel must insert a process in the semaphore list and then suspend it. Because both operations are relatively expensive, in the time it takes to complete them, the other kernel control path could have already released the semaphore. In these cases, multiprocessor operating systems use spin locks . A spin lock is very similar to a semaphore, but it has no process list; when a process finds the lock closed by another process, it "spins" around repeatedly, executing a tight instruction loop until the lock becomes open. Of course, spin locks are useless in a uniprocessor environment. When a kernel control path tries to access a locked data structure, it starts an endless loop. Therefore, the kernel control path that is updating the protected data structure would not have a chance to continue the execution and release the spin lock. The final result would be that the system hangs.

http://en.wikipedia.org/wiki/Fast_retransmit

Fast Retransmit is an enhancement to TCP which reduces the time a sender waits before retransmitting a lost segment.

A TCP sender uses timers to recognize lost segments. If an acknowledgement is not received for a particular segment within a specified time (a function of the estimated Round-trip delay time), the sender will assume the segment was lost in the network, and will retransmit the segment.

The fast retransmit enhancement works as follows: if a TCP sender receives three duplicate acknowledgements with the same acknowledge number (that is, a total of four acknowledgements with the same acknowledgement number), the sender can be reasonably confident that the segment with the next higher sequence number was dropped, and will not arrive out of order. The sender will then retransmit the packet that was presumed dropped before waiting for its timeout.

 

今天和David去了十三陵，上次见面还是深冬，转眼已是初夏，先走了常规路线，然后顺道把几个没开放的陵也看了一道，地图如下

 

 

路线如下

定陵－－昭陵－－长陵－－献陵－－庆陵－－裕陵－－茂陵－－泰陵

皇帝陵讲究的是风水，遵循的是旧制，也就没有了什么精彩之处可言，格局大同小异，看得就是历史背后的故事，一个帝陵的大小，修缮的程度，也反映了当时国运的兴衰。

加上大二时候在南京看的明孝陵，在娘娘坟看的景泰陵，明皇陵算是看过了五分之八。

 

 

定陵地宫的这道门分隔了生死，万历皇帝的棺椁都已经是后来的复制了，文革的浩劫，连尸骨都没有放过。

 

 

就如每个中国男人心中都有的皇帝梦一样，中国女人看到这样的凤冠，是不是同样浮想联翩

 

 

破败的裕陵，是不是也代表了明英宗土木堡之变的耻辱，相比而言，还是在娘娘坟那可怜的明代宗的墓稍微像样一些。

 

1. sudo gvim /etc/network/interfaces: 
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet dhcp
        bridge_ports eth0

2. sudo /etc/init.d/networking restart
3. install guest os
4. modify /etc/libvirt/qemu/guest_os_name.xml
    <interface type='bridge'>
      <mac address='your mac address'/>
      <source bridge='br0'/>
    </interface>
5. sudo virsh define guest_os_name.xml
6. start kvm again