Linux核心程序詳解之一:sync_supers
先說下環境,CentOS 6.0/Linux kernel 2.6.38.8/X86-64,後面提到的程式碼也都來之kernel 2.6.38.8。這個環節下的程序列表具體如下所示,後續將有一系列的文章分析各個程序(主要是核心程序)的功能:
[[email protected] ~]# cat /etc/issue
CentOS Linux release 6.0 (Final)
Kernel \r on an \m
[[email protected] ~]# uname -a
Linux localhost.localdomain 2.6.38.8 #4 SMP Mon Oct 31 20:49:48 CST 2011 x86_64 x86_64 x86_64 GNU/Linux
[ [email protected] ~]# ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 19284 1368 ? Ss Feb06 0:02 /sbin/init
root 2 0.0 0.0 0 0 ? S Feb06 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S Feb06 0:00 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S Feb06 0:20 [kworker/u:0]
root 6 0.0 0.0 0 0 ? S Feb06 0:00 [migration/0]
root 7 0.0 0.0 0 0 ? S Feb06 0:00 [migration/1]
root 9 0.0 0.0 0 0 ? S Feb06 0:00 [ksoftirqd/1]
root 11 0.0 0.0 0 0 ? S< Feb06 0:00 [cpuset]
root 12 0.0 0.0 0 0 ? S< Feb06 0:00 [khelper]
root 13 0.0 0.0 0 0 ? S< Feb06 0:00 [netns]
root 14 0.0 0.0 0 0 ? S Feb06 0:01 []
root 15 0.0 0.0 0 0 ? S Feb06 0:00 [bdi-default]
root 16 0.0 0.0 0 0 ? S< Feb06 0:00 [kintegrityd]
root 17 0.0 0.0 0 0 ? S< Feb06 0:00 [kblockd]
root 18 0.0 0.0 0 0 ? S< Feb06 0:00 [kacpid]
root 19 0.0 0.0 0 0 ? S< Feb06 0:00 [kacpi_notify]
root 20 0.0 0.0 0 0 ? S< Feb06 0:00 [kacpi_hotplug]
root 21 0.0 0.0 0 0 ? S< Feb06 0:00 [ata_sff]
root 22 0.0 0.0 0 0 ? S Feb06 0:00 [khubd]
root 23 0.0 0.0 0 0 ? S< Feb06 0:00 [md]
root 24 0.0 0.0 0 0 ? S Feb06 0:00 [khungtaskd]
root 25 0.0 0.0 0 0 ? S Feb06 0:05 [kswapd0]
root 26 0.0 0.0 0 0 ? SN Feb06 0:00 [ksmd]
root 27 0.0 0.0 0 0 ? SN Feb06 0:02 [khugepaged]
root 28 0.0 0.0 0 0 ? S Feb06 0:00 [fsnotify_mark]
root 29 0.0 0.0 0 0 ? S< Feb06 0:00 [aio]
root 30 0.0 0.0 0 0 ? S< Feb06 0:00 [crypto]
root 35 0.0 0.0 0 0 ? S Feb06 0:20 [kworker/u:1]
root 37 0.0 0.0 0 0 ? S< Feb06 0:00 [kpsmoused]
root 175 0.0 0.0 0 0 ? S Feb06 0:00 [scsi_eh_0]
root 176 0.0 0.0 0 0 ? S Feb06 0:42 [scsi_eh_1]
root 182 0.0 0.0 0 0 ? S< Feb06 0:00 [mpt_poll_0]
root 183 0.0 0.0 0 0 ? S< Feb06 0:00 [mpt/0]
root 184 0.0 0.0 0 0 ? S Feb06 0:00 [scsi_eh_2]
root 240 0.0 0.0 0 0 ? S< Feb06 0:00 [kdmflush]
root 247 0.0 0.0 0 0 ? S< Feb06 0:00 [kdmflush]
root 259 0.0 0.0 0 0 ? S Feb06 0:19 [jbd2/dm-0-8]
root 260 0.0 0.0 0 0 ? S< Feb06 0:00 [ext4-dio-unwrit]
root 297 0.0 0.0 0 0 ? S Feb06 0:01 [kauditd]
root 346 0.0 0.1 11700 1820 ? S<s Feb06 0:00 /sbin/udevd -d
root 565 0.0 0.0 0 0 ? S Feb06 0:05 [flush-253:0]
root 681 0.0 0.0 0 0 ? S< Feb06 0:00 [vmmemctl]
root 757 0.0 0.0 0 0 ? S< Feb06 0:00 [kdmflush]
root 801 0.0 0.0 0 0 ? S Feb06 0:00 [jbd2/sda1-8]
root 802 0.0 0.0 0 0 ? S< Feb06 0:00 [ext4-dio-unwrit]
root 803 0.0 0.0 0 0 ? S Feb06 0:00 [jbd2/dm-2-8]
root 804 0.0 0.0 0 0 ? S< Feb06 0:00 [ext4-dio-unwrit]
root 912 0.0 0.3 12880 3108 ? S< Feb06 0:00 /sbin/udevd -d
root 924 0.0 0.2 12356 2648 ? S< Feb06 0:00 /sbin/udevd -d
root 1114 0.0 0.1 242492 1540 ? Sl Feb06 0:05 /sbin/rsyslogd -c 4
root 1143 0.0 0.0 9104 428 ? Ss Feb06 1:04 irqbalance
rpc 1162 0.0 0.0 18920 816 ? Ss Feb06 0:01 rpcbind
root 1176 0.0 0.0 6604 260 ? Ss Feb06 0:00 mdadm --monitor --scan -f --pid-file=/var/run/mdadm/mdadm.pid
dbus 1185 0.0 0.1 29964 1448 ? Ssl Feb06 0:00 dbus-daemon --system
root 1196 0.0 0.3 95412 3468 ? Ssl Feb06 0:00 NetworkManager --pid-file=/var/run/NetworkManager/NetworkManager.pid
root 1202 0.0 0.1 55792 2000 ? S Feb06 0:00 /usr/sbin/modem-manager
avahi 1212 0.0 0.1 27820 1392 ? S Feb06 0:00 avahi-daemon: running [linux.local]
avahi 1213 0.0 0.0 27696 188 ? Ss Feb06 0:00 avahi-daemon: chroot helper
root 1221 0.0 0.1 9064 1360 ? S Feb06 0:04 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-client.action -pf /var/run/dhclient-eth3.pid -lf /var/lib/dhclient/dhclient-aacaa3a9-81be-441d-ba72-cec0c023b1f8-eth3.lease -cf /var/run/nm-dhclient-eth3.conf eth3
root 1235 0.0 0.0 39232 388 ? Ss Feb06 0:00 /usr/sbin/wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -B -u -f /var/log/wpa_supplicant.log -P /var/run/wpa_supplicant.pid
rpcuser 1236 0.0 0.1 23088 1124 ? Ss Feb06 0:00 rpc.statd
root 1251 0.0 0.0 4020 508 tty1 Ss+ Feb11 0:00 /sbin/mingetty /dev/tty1
root 1280 0.0 0.0 0 0 ? S< Feb06 0:00 [rpciod]
root 1287 0.0 0.0 27336 396 ? Ss Feb06 0:00 rpc.idmapd
root 1297 0.0 0.2 178584 2840 ? Ss Feb06 0:00 cupsd -C /etc/cups/cupsd.conf
root 1322 0.0 0.0 4036 604 ? Ss Feb06 0:00 /usr/sbin/acpid
68 1331 0.0 0.3 26184 3252 ? Ss Feb06 0:03 hald
root 1332 0.0 0.1 18068 1136 ? S Feb06 0:00 hald-runner
root 1375 0.0 0.0 20184 832 ? S Feb06 0:00 hald-addon-input: Listening on /dev/input/event0 /dev/input/event1
root 1376 0.0 0.0 20180 856 ? S Feb06 0:18 hald-addon-storage: no polling on /dev/fd0 because it is explicitly disabled
68 1377 0.0 0.0 17760 988 ? S Feb06 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket
root 1380 0.0 0.0 20180 856 ? S Feb06 1:29 hald-addon-storage: polling /dev/sr0 (every 2 sec)
root 1397 0.0 0.1 89180 1420 ? Ssl Feb06 0:00 pcscd
root 1418 0.0 0.3 381500 3368 ? Ssl Feb06 0:38 automount --pid-file /var/run/autofs.pid
root 1452 0.0 0.1 63804 1316 ? Ss Feb06 0:00 /usr/sbin/sshd
root 1478 0.0 0.0 22020 880 ? Ss Feb06 0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
root 1579 0.0 0.2 62020 2716 ? Ss Feb06 0:03 /usr/libexec/postfix/master
postfix 1586 0.0 0.2 62168 2436 ? S Feb06 0:00 qmgr -l -t fifo -u
root 1590 0.0 0.8 263516 8848 ? Ss Feb06 1:25 /usr/sbin/abrtd
root 1604 0.0 0.0 108292 944 ? S Feb06 0:47 /bin/bash /usr/sbin/ksmtuned
qpidd 1616 0.0 0.2 314868 3052 ? Ssl Feb06 0:27 /usr/sbin/qpidd --data-dir /var/lib/qpidd --daemon
root 1646 0.0 0.1 117072 1324 ? Ss Feb06 0:06 crond
root 1657 0.0 0.0 21360 156 ? Ss Feb06 0:00 /usr/sbin/atd
root 1668 0.0 1.0 268400 10880 ? Sl Feb06 0:01 libvirtd --daemon
root 1733 0.0 0.0 4020 504 tty2 Ss+ Feb06 0:00 /sbin/mingetty /dev/tty2
root 1737 0.0 0.0 4020 508 tty3 Ss+ Feb06 0:00 /sbin/mingetty /dev/tty3
root 1740 0.0 0.0 4020 504 tty4 Ss+ Feb06 0:00 /sbin/mingetty /dev/tty4
root 1742 0.0 0.0 4020 504 tty5 Ss+ Feb06 0:00 /sbin/mingetty /dev/tty5
root 1745 0.0 0.0 4020 500 tty6 Ss+ Feb06 0:00 /sbin/mingetty /dev/tty6
nobody 1761 0.0 0.0 12840 564 ? S Feb06 0:00 /usr/sbin/dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253 --dhcp-no-override
root 1780 0.0 0.2 4111744 2592 ? Sl Feb06 0:00 /usr/sbin/console-kit-daemon --no-daemon
root 1886 0.0 0.0 25536 704 ? S<sl Feb06 0:01 auditd
root 14757 0.0 0.3 97484 3636 ? Ss 14:57 0:00 sshd: [email protected]/0
root 14761 0.0 0.1 108296 1832 pts/0 Ss 14:57 0:00 -bash
root 14858 0.0 0.3 97484 3640 ? Ss 15:01 0:00 sshd: [email protected]/1
root 14862 0.0 0.1 108424 1868 pts/1 Ss+ 15:01 0:00 -bash
root 14987 0.0 0.3 97484 3636 ? Ss 15:04 0:00 sshd: [email protected] /2
root 14991 0.0 0.1 108296 1680 pts/2 Ss+ 15:04 0:00 -bash
root 15049 0.0 0.0 0 0 ? S 15:08 0:00 [kworker/1:0]
postfix 15321 0.0 0.2 62100 2656 ? S 15:31 0:00 pickup -l -t fifo -u
root 15401 0.1 0.0 0 0 ? S 15:38 0:01 [kworker/0:1]
root 15518 0.0 0.0 0 0 ? S 15:48 0:00 [kworker/0:0]
root 15556 0.0 0.0 0 0 ? S 15:50 0:00 [kworker/1:2]
root 15582 0.0 0.0 0 0 ? S 15:53 0:00 [kworker/0:2]
root 15727 0.0 0.0 0 0 ? S 16:03 0:00 [kworker/1:1]
root 15791 0.0 0.0 100864 456 ? S 16:07 0:00 sleep 60
root 15793 0.0 0.1 107968 1052 pts/0 R+ 16:07 0:00 ps aux
root 25845 0.0 0.0 0 0 ? S Feb07 0:00 [jbd2/sdb1-8]
root 25846 0.0 0.0 0 0 ? S< Feb07 0:00 [ext4-dio-unwrit]
sync_supers核心執行緒功能專一,用來同步作業系統當前掛載的各個檔案系統的超級塊資料,由於超級塊對於檔案系統的特殊性,所以這對保證檔案系統的完整性至關重要。
在原始檔mm/backing-dev.c內可以看到sync_supers核心執行緒的建立:
static int __init default_bdi_init(void)
{
int err;
sync_supers_tsk = kthread_run(bdi_sync_supers, NULL, "sync_supers");
BUG_ON(IS_ERR(sync_supers_tsk));
setup_timer(&sync_supers_timer, sync_supers_timer_fn, 0);
bdi_arm_supers_timer();
err = bdi_init(&default_backing_dev_info);
if (!err)
bdi_register(&default_backing_dev_info, NULL, "default");
err = bdi_init(&noop_backing_dev_info);
return err;
}
subsys_initcall(default_bdi_init);
void bdi_arm_supers_timer(void)
{
unsigned long next;
if (!dirty_writeback_interval)
return;
next = msecs_to_jiffies(dirty_writeback_interval * 10) + jiffies;
mod_timer(&sync_supers_timer, round_jiffies_up(next));
}
/*
* The interval between `kupdate'-style writebacks
*/
unsigned int dirty_writeback_interval = 5 * 100; /* centiseconds */
通過函式bdi_arm_supers_timer()設定定時器,預設每隔5秒喚醒sync_supers核心執行緒執行具體的操作函式sync_supers():
/*
* kupdated() used to do this. We cannot do it from the bdi_forker_thread()
* or we risk deadlocking on ->s_umount. The longer term solution would be
* to implement sync_supers_bdi() or similar and simply do it from the
* bdi writeback thread individually.
*/
static int bdi_sync_supers(void *unused)
{
set_user_nice(current, 0);
while (!kthread_should_stop()) {
set_current_state(TASK_INTERRUPTIBLE);
schedule();
/*
* Do this periodically, like kupdated() did before.
*/
sync_supers();
}
return 0;
}
/**
* sync_supers - helper for periodic superblock writeback
*
* Call the write_super method if present on all dirty superblocks in
* the system. This is for the periodic writeback used by most older
* filesystems. For data integrity superblock writeback use
* sync_filesystems() instead.
*
* Note: check the dirty flag before waiting, so we don't
* hold up the sync while mounting a device. (The newly
* mounted device won't need syncing.)
*/
void sync_supers(void)
{
struct super_block *sb, *p = NULL;
spin_lock(&sb_lock);
list_for_each_entry(sb, &super_blocks, s_list) {
if (list_empty(&sb->s_instances))
continue;
if (sb->s_op->write_super && sb->s_dirt) {
sb->s_count++;
spin_unlock(&sb_lock);
down_read(&sb->s_umount);
if (sb->s_root && sb->s_dirt)
sb->s_op->write_super(sb);
up_read(&sb->s_umount);
spin_lock(&sb_lock);
if (p)
__put_super(p);
p = sb;
}
}
if (p)
__put_super(p);
spin_unlock(&sb_lock);
}
sync_supers函式邏輯非常簡單,遍歷所有超級塊(通過核心提供的全域性連結串列super_blocks,這個全域性連結串列儲存了作業系統當前所有掛載檔案系統的super_block例項),如果例項不存在則continue下一個,如果例項存在則接著判斷同步回寫函式write_super是否存在(有些檔案系統,例如虛擬的檔案系統或基於實體記憶體的檔案系統並不需要進行同步操作,所以可以不提供回寫函式write_super,典型示例就是/proc檔案系統)以及超級塊是否髒而需要進行同步。
各個需要進行超級塊資料同步的檔案系統都會提供適當的回寫函式,比如ext4:
static void ext4_write_super(struct super_block *sb)
{
lock_super(sb);
ext4_commit_super(sb, 1);
unlock_super(sb);
}
static int ext4_commit_super(struct super_block *sb, int sync)
{
struct ext4_super_block *es = EXT4_SB(sb)->s_es;
struct buffer_head *sbh = EXT4_SB(sb)->s_sbh;
int error = 0;
if (!sbh)
return error;
if (buffer_write_io_error(sbh)) {
/*
* Oh, dear. A previous attempt to write the
* superblock failed. This could happen because the
* USB device was yanked out. Or it could happen to
* be a transient write error and maybe the block will
* be remapped. Nothing we can do but to retry the
* write and hope for the best.
*/
ext4_msg(sb, KERN_ERR, "previous I/O error to "
"superblock detected");
clear_buffer_write_io_error(sbh);
set_buffer_uptodate(sbh);
}
/*
* If the file system is mounted read-only, don't update the
* superblock write time. This avoids updating the superblock
* write time when we are mounting the root file system
* read/only but we need to replay the journal; at that point,
* for people who are east of GMT and who make their clock
* tick in localtime for Windows bug-for-bug compatibility,
* the clock is set in the future, and this will cause e2fsck
* to complain and force a full file system check.
*/
if (!(sb->s_flags & MS_RDONLY))
es->s_wtime = cpu_to_le32(get_seconds());
if (sb->s_bdev->bd_part)
es->s_kbytes_written =
cpu_to_le64(EXT4_SB(sb)->s_kbytes_written +
((part_stat_read(sb->s_bdev->bd_part, sectors[1]) -
EXT4_SB(sb)->s_sectors_written_start) >> 1));
else
es->s_kbytes_written =
cpu_to_le64(EXT4_SB(sb)->s_kbytes_written);
ext4_free_blocks_count_set(es, percpu_counter_sum_positive(
&EXT4_SB(sb)->s_freeblocks_counter));
es->s_free_inodes_count =
cpu_to_le32(percpu_counter_sum_positive(
&EXT4_SB(sb)->s_freeinodes_counter));
sb->s_dirt = 0;
BUFFER_TRACE(sbh, "marking dirty");
mark_buffer_dirty(sbh);
if (sync) {
error = sync_dirty_buffer(sbh);
if (error)
return error;
error = buffer_write_io_error(sbh);
if (error) {
ext4_msg(sb, KERN_ERR, "I/O error while writing "
"superblock");
clear_buffer_write_io_error(sbh);
set_buffer_uptodate(sbh);
}
}
return error;
}
int sync_dirty_buffer(struct buffer_head *bh)
{
return __sync_dirty_buffer(bh, WRITE_SYNC);
}
EXPORT_SYMBOL(sync_dirty_buffer);
相關推薦
Linux核心程序詳解之一:sync_supers
先說下環境,CentOS 6.0/Linux kernel 2.6.38.8/X86-64,後面提到的程式碼也都來之kernel 2.6.38.8。這個環節下的程序列表具體如下所示,後續將有一系列的文章分析各個程序(主要是核心程序)的功能: [[email pro
Linux核心程序詳解之三:flush-x:y
上一篇文章《裝置檔案與裝置號》當然不是突然穿插而來的自言自語,而是理解本文的前提,下面來看。是一類程序,這在系列的上一篇文章裡已經講到過,系統的絕大部分的bdi裝置都會有對應的flush-x:y核心程序,而這個x:y是對應bdi裝置的裝置號。 先看一下系統當前掛載的檔案系統
linux核心sysfs詳解-1
sysfs 是 Linux 核心中設計較新的一種虛擬的基於記憶體的檔案系統,它的作用與 proc 有些類似,但除了與 proc 相同的具有檢視和設定核心引數功能之外,還有為 Linux 統一裝置模型作為管理之用。相比於 proc 檔案系統,使用 sysfs 匯出核心資料的方
ALSA音效卡驅動中的DAPM詳解之一:kcontrol
DAPM是Dynamic Audio Power Management的縮寫,直譯過來就是動態音訊電源管理的意思,DAPM是為了使基於linux的移動裝置上的音訊子系統,在任何時候都工作在最小功耗狀態下。DAPM對使用者空間的應用程式來說是透明的,所有與電源相關的開關都在A
ServletContext物件詳解之一:什麼是ServletContext物件
前面幾篇博文我們瞭解了Servlet、servlet物件以及servlet的生命週期,這篇博文將介紹另一非常重要的概念:ServletContext物件。1.什麼是ServletContext物件 ServletContext代表一個web應用環境物件,即一個web環境
Async詳解之一:流程控制
為了適應非同步程式設計,減少回撥的巢狀,我嘗試了很多庫。最終覺得還是async最靠譜。 Async的內容分為三部分: 流程控制:簡化十種常見流程的處理 集合處理:如何使用非同步操作處理集合中的資料 工具類:幾個常用的工具類 本文介紹其中最簡單最常用的流程控制部分。
Linux核心編譯詳解
學習了網上的一些資料,自己試著摸索了一下,整理出此文。 由於在下水平相當有限,不當之處,還望大家批評指正^_^ 重要的參考資料有: 好了,下面進入正題。 一、準備工作 準備工作如何做,這裡就不詳說了。 a) 首先,你要有一臺PC(這不廢話麼^_^),裝好了Lin
OpenCV中矩陣類詳解之一:Mat
Mat::eye 返回一個恆等指定大小和型別矩陣。 C++: static MatExpr Mat::eye(int rows, int cols, inttype) C++: static MatExpr Mat::eye(Size size, int type) 引數 rows –的行數。
linux守護程序詳解及建立,daemon()使用
Linux Daemon(守護程序)是執行在後臺的一種特殊程序。它獨立於控制終端並且週期性地執行某種任務或等待處理某些發生的事件。它不需要使用者輸入就能執行而且提供某種服務,不是對整個系統就是對某個使用者程式提供服務。Linux系統的大多數伺服器就是通過守護程序實現的。常見的守護程序包括系統日誌程序sysl
Linux核心引數詳解
核心引數詳解 長期更新 SYN_RECV 服務端收到sys,還未發出syn+ack 1.net.ipv4.tcp_synack_retries 預設值5,linux對應1+2+4+..32=2^6-1=63s 2.net.ipv4.tcp_s
linux驅動由淺入深系列:PBL-SBL1-(bootloader)LK-Android啟動過程詳解之一(高通MSM8953啟動例項)【轉】
本文轉載自:https://blog.csdn.net/radianceblau/article/details/73229005 對於嵌入式工程師瞭解晶片啟動過程是十分有必要的,在分析、除錯各種問題的時候都有可能涉及到這方面的知識。同時這部分知識也是比較複雜的,因為其中涉及到晶片內部架構,啟動各個階段軟體
linux系統程式設計之程序(八):守護程序詳解及建立,daemon()使用
一,守護程序概述 Linux Daemon(守護程序)是執行在後臺的一種特殊程序。它獨立於控制終端並且週期性地執行某種任務或等待處理某些發生的事件。它不需要使用者輸入就能執行而且提供某種服務,不是對整個系統就是對某個使用者程式提供服務。Linux系統的大多數伺服器就是通過守護程序實現的。常見的守護程序包括系
詳解Linux核心程序排程函式schedule()的觸發和執行時機
核心的排程操作分為觸發和執行兩個部分,觸發時僅僅設定一下當前程序的TIF_NEED_RESCHED標誌,執行的時候則是通過schedule()函式來完成程序的選擇和切換。當前程序的thread_info->flags中TIF_NEED_RESCHED位表示需要呼叫schedule()函式進行排程。核心在
Linux如何實現開機啟動程序詳解(轉)
window 自己的 進行 執行時間 dns服務 全部 星期 ext 例如 Linux開機啟動程序詳解我們假設大家已經熟悉其它操作系統的引導過程,了解硬件的自檢引導步驟,就只從Linux操作系統的引導加載程序(對個人電腦而言通常是LILO)開始,介紹Linux開機引導的步驟
linux每日命令(26):Linux檔案屬性詳解
Linux 檔案或目錄的屬性主要包括:檔案或目錄的節點、種類、許可權模式、連結數量、所歸屬的使用者和使用者組、最近訪問或修改的時間等內容。具體情況如下: 命令: ls -lih 輸出: [[email protected] test]# ls -lih total 0 51621141 dr
Linux核心調整和核心引數詳解
SYN COOKIE原理和Linux核心中的實現 http://www.ibm.com/developerworks/cn/linux/l-syncookie/?ca=dwcn-newsletter-linux Linux系統下的DDOS攻擊防範 http://hi.baidu.com/mo
linux核心優化,核心引數詳解
轉自百度文庫,最後有一部分修改: 一、前言 本文件針對OOP8生產環境,具體優化策略需要根據實際情況進行調整;本文件將在以下幾個方面來闡述如何針對RedHat Enterprise Linux進行效能優化。 1) Linux Proc檔案系統,通過對Proc檔案
前端基礎進階(12):深入核心,詳解事件迴圈機制
Event Loop JavaScript的學習零散而龐雜,因此很多時候我們學到了一些東西,但是卻沒辦法感受到自己的進步,甚至過了不久,就把學到的東西給忘了。為了解決自己的這個困擾,在學習的過程中,我一直試圖在尋找一條核心的線索,只要我根據這條線索,我就能夠一點一點的進步。 前端基礎進階正是圍繞這條線索
Linux系統呼叫詳解(如何從使用者空間進入核心空間)
系統呼叫概述 計算機系統的各種硬體資源是有限的,在現代多工作業系統上同時執行的多個程序都需要訪問這些資源,為了更好的管理這些資源程序是不允許直接操作的,所有對這些資源的訪問都必須有作業系統控制。也就是說作業系統是使用這些資源的唯一入口,而這個入口就是作業系
linux核心剖析---Linux系統呼叫詳解(實現機制分析)
本文介紹了系統呼叫的一些實現細節。首先分析了系統呼叫的意義,它們與庫函式和應用程式介面(API)有怎樣的關係。然後,我們考察了Linux核心如何實現系統呼叫,以及執行系統呼叫的連鎖反應:陷入核心,傳遞系統呼叫號和引數,執行正確的系統呼叫函式,並把返回值帶回使用者空間。最後