在 Docker 中使用 cfs_quota 控制CPU，导致内核崩溃：CPU: 27 PID: 89704 Comm: exe Tainted: G C 3.16.0-4-am
- 在 Docker 中使用 cfs_quota 控制CPU，导致内核崩溃：
CPU: 27 PID: 89704 Comm: exe Tainted: G C 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3Hardware name: Dell Inc. PowerEdge M630/0PHY8D, BIOS 1.4.5 10/26/2015task: ffff88084b5df2b0 ti: ffff880855214000 task.ti: ffff880855214000RIP: 0010:[<ffffffff8109f954>] [<ffffffff8109f954>] check_preempt_wakeup+0xd4/0x1d0RSP: 0018:ffff880855217e60 EFLAGS: 00010097RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000008RDX: 0000000000000000 RSI: ffff880fe065b4b0 RDI: ffff881055b9ae00RBP: ffff880dfdfc01c0 R08: ffffffff81610960 R09: 0000000000000001R10: 0000000000000000 R11: 0000000000000000 R12: ffff8810007fa250R13: ffff88107f1d2f00 R14: 0000000000000000 R15: 0000000000000000FS: 00007f5ed7b7d740(0000) GS:ffff88107f1a0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000078 CR3: 000000068f84a000 CR4: 00000000001407e0Stack: 0000000000012f00 ffff88107f1d2f00 ffff880fe065b4b0 ffff88107f1d2f00 ffff880fe065bb34 0000000000000246 ffff880fddde0ac0 ffffffff81094565 0000000000012f00 ffffffff810969ea 00007fffffffeffd ffff880fe065b4b0Call Trace: [<ffffffff81094565>] ? check_preempt_curr+0x85/0xa0 [<ffffffff810969ea>] ? wake_up_new_task+0xda/0x160 [<ffffffff8106698c>] ? do_fork+0x13c/0x390 [<ffffffff81514579>] ? stub_clone+0x69/0x90 [<ffffffff8151420d>] ? system_call_fast_compare_end+0x10/0x15RIP [<ffffffff8109f954>] check_preempt_wakeup+0xd4/0x1d0 RSP <ffff880855217e60>CR2: 0000000000000078- Docker信息如下（Bug说明 #13940）：
# docker infoContainers: 99 Running: 14 Paused: 0 Stopped: 85Images: 49Server Version: 1.12.0Storage Driver: aufs Root Dir: /docker/aufs Backing Filesystem: xfs Dirs: 402 Dirperm1 Supported: trueLogging Driver: json-fileCgroup Driver: cgroupfsPlugins: Volume: local Network: bridge macvlan host null overlaySwarm: pending NodeID: 526qb3beuge4zn9urapmu4uh6 Is Manager: false Node Address: 192.168.22.33Runtimes: runcDefault Runtime: runcSecurity Options:Kernel Version: 3.16.7-ckt25Operating System: Debian GNU/Linux 8 (jessie)OSType: linuxArchitecture: x86_64CPUs: 48Total Memory: 62.82 GiBName: shd-docker-03ID: MFNF:NBGM:2VYN:HLA4:XRWT:EBFI:LZTV:VHVX:5VA6:BAJC:JNXB:AHHGDocker Root Dir: /dockerDebug Mode (client): falseDebug Mode (server): true File Descriptors: 112 Goroutines: 211 System Time: 2016-09-10T02:46:40.356550459+08:00 EventsListeners: 2Registry: https://index.docker.io/v1/Insecure Registries: 127.0.0.0/8挑当前最新 LongTerm 版本：
下载、编译、打包 内核过程记录如下：
aptitude -y install fakeroot kernel-package libncurses5-dev build-essentiallftp -c 'pget -n 30 https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.4.20.tar.xz'tar -axf linux-4.4.20.tar.xzcp /boot/config-$(uname -r) linux-4.4.20/.configmake menuconfig# General setup ---> Control Group support ---> Group CPU scheduler （全勾选） make -j 24 deb-pkgls ../*.deb然而不幸的是，使用新内核无法启动（惨不能睹）：
原来升级内核也要讲究顺序的：
wget 192.169.23.233:2333/{linux-image-4.4.20_4.4.20-1_amd64.deb,linux-libc-dev_4.4.20-1_amd64.deb,linux-firmware-image-4.4.20_4.4.20-1_amd64.deb}dpkg -i linux-libc-dev_4.4.20-1_amd64.debdpkg -i linux-firmware-image-4.4.20_4.4.20-1_amd64.debdpkg -i linux-image-4.4.20_4.4.20-1_amd64.debvi /etc/default/grubupdate-grubrebootuname -a
- 4.4 启动过程卡且慢，ssh登录后手动操作感觉到卡顿。回退到 4.1 版本则正常~
