sudo apt-get install build-essential 来下载并安装gcc，而且系统还会自己帮你下载一些C语言的库。
第二，在虚拟机下安装了ubuntu中要输入用户名，一般情况下大家都会输入一个自己的网名或绰号之类的，密码也在这时设置过了。 但是当安装成功之后，使用命令#su root，然后输入刚才设置的密码，发现密码错误，至始至终我就设置过一次密码，怎么会错误，原来，在ubuntu系统下，为了安全起见，在安装过程中，系统屏蔽了用户设置root用户。导致很多用户在使用过程中不知道root密码到底是什么。重新设置root密码的方法如下：
1.在当前终端输入sudo passwd(回车)
2.Password: <--- 输入你当前用户的密码
输入你现在用户的密码后系统会出现：
Enter new UNIX password: <--- 新的Root用户密码
Retype new UNIX password: <--- 重复新的Root用户密码
passwd：已成功更新密码
现在，你可以使用命令 su ，接着输入root密码，你就可以变成root权限咯。当你想从root变成普通用户时，只需要输入命令 su 普通用户名 ,然后就会切换用户，并且此时不需要输入普通用户的密码，因为root权限比较高呗！
参考：http://www.cnblogs.com/lidan/archive/2011/07/31/2239495.html
本文链接
几个重要的名词
- HZ：系统定时器频率HZ用来定义系统定时器每隔1秒产生多少个时钟中断
- Tick：HZ的倒数，系统定时器两次时钟中断的时间间隔
- Xtime：记录Wall time值，也就是UTC时间，是一个struct timeval结构，在用户空间通过gettimeofday读取
- Jiffies：记录系统开机以来经过了多少次Tick，定义为unsigned long volatile __jiffy_data jiffies;
- RTC：实时时钟，是一个硬件时钟，用来持久存放系统时间
HZ
HZ是静态编译到内核中的，其定义如下：
// /usr/include/asm-generic/param.h文件中
#ifdef __KERNEL__
# define HZ CONFIG_HZ /* Internal kernel timer frequency */
# define USER_HZ 100 /* some user interfaces are */
# define CLOCKS_PER_SEC (USER_HZ) /* in "ticks" like times() */
#endif
#ifndef HZ
#define HZ 100
#endif
在2.6以前的内核中，如果改变内核中的HZ值会给用户空间中某些程序造成异常结果。因为内核是以节拍数/秒的形式给用户空间导出这个值的，应用程序便依赖这个特定的HZ值。如果在内核中改变了HZ的定义值，就打破了用户空间的常量关系---用户空间并不知道新的HZ值。
内核更改所有导出的jiffies值。内核定义了USER_HZ来代表用户空间看到的HZ值。在x86体系结构上，由于HZ值原来一直是100，所以USER_HZ值就定义为100。内核可以使用宏jiffies_to_clock_t()将一个有HZ表示的节拍计数转换为一个由USER_HZ表示的节拍计数：
start=jiffies;
//doing some jobs
total_time=jiffies-start;
ticks=jiffies_to_clock_t(total_time);
jiffies_to_clock_t()函数的定义如下：
/*
* Convert jiffies/jiffies_64 to clock_t and back.
*/
clock_t jiffies_to_clock_t(unsigned long x)
{
#if (TICK_NSEC % (NSEC_PER_SEC / USER_HZ)) == 0
# if HZ < USER_HZ
return x * (USER_HZ / HZ);
# else
return x / (HZ / USER_HZ);
# endif
#else
return div_u64((u64)x * TICK_NSEC, NSEC_PER_SEC / USER_HZ);
#endif
}
Jiffies
Jiffies记录了系统启动以来所经过的ticks数，在开机时该值是0，随后每次时钟中断发生时加1.
根据jiffies可以计算系统的开机时间：jiffies/HZ 秒
Jiffies的定义为unsigned long volatile __jiffy_data jiffies;
由于jiffies存在溢出的可能，内核定义了一组辅助函数来处理jiffies的比较操作，操作jiffies时最好使用这些辅助函数：
/*
* These inlines deal with timer wrapping correctly. You are
* strongly encouraged to use them
* 1. Because people otherwise forget
* 2. Because if the timer wrap changes in future you won't have to
* alter your driver code.
*
* time_after(a,b) returns true if the time a is after time b.
*
* Do this with "<0" and ">=0" to only test the sign of the result. A
* good compiler would generate better code (and a really good compiler
* wouldn't care). Gcc is currently neither.
*/
#define time_after(a,b) \
(typecheck(unsigned long, a) && \
typecheck(unsigned long, b) && \
((long)(b) - (long)(a) < 0))
#define time_before(a,b) time_after(b,a)
#define time_after_eq(a,b) \
(typecheck(unsigned long, a) && \
typecheck(unsigned long, b) && \
((long)(a) - (long)(b) >= 0))
#define time_before_eq(a,b) time_after_eq(b,a)
实时时钟RTC
实时时钟是一个硬件时钟，用来持久存放系统时间，系统关闭后靠主板上的微型电池保持计时；
系统启动时，内核通过读取RTC来初始化Wall Time, 并存放在xtime变量中，这是RTC最主要的作用；
当用户修改了时间后，可以用hwclock –w将其保存到RTC中。
系统定时器
每个PC机中都有一个PIT，以通过IRQ0产生周期性的时钟中断信号,作为系统定时器 system timer。当发生时钟中断时，就会自动调用时钟中断处理程序。
时钟中断处理程序分为两个部分：体系结构相关部分和体系结构无关部分。相关的部分作为系统定时器的中断处理程序而注册到内核中，以便在产生时钟中断时，它能够相应地运行。执行的工作如下：
1.获得xtime_lock锁，以便对访问jiffies_64和墙上时间xtime进行保护。
2.需要时应答或重新设置系统时钟。
3.周期性地使用墙上时间更新实时时钟。
4.调用体系结构无关的时间例程：do_timer().
中断服务程序主要通过调用与体系结构无关的例程do_timer()执行下面的工作：
1.给jiffies_64变量加1.
你可能对于 Linux 的负载均值（load averages）已有了充分的了解。负载均值在 uptime 或者 top 命令中可以看到，它们可能会显示成这个样子：
load average: 0.09, 0.05, 0.01很多人会这样理解负载均值：三个数分别代表不同时间段的系统平均负载（一分钟、五 分钟、以及十五分钟），它们的数字当然是越小越好。数字越高，说明服务器的负载越 大，这也可能是服务器出现某种问题的信号。
而事实不完全如此，是什么因素构成了负载均值的大小，以及如何区分它们目前的状况是 「好」还是「糟糕」？什么时候应该注意哪些不正常的数值？
回答这些问题之前，首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明， 一台只配备一块单核处理器的服务器。
行车过桥一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥 费 -- 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。 如果车辆众多，那么需要告知他们可能需要稍等一会。
因此，需要些特定的代号表示目前的车流情况，例如：
- 0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。
- 1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢。
- 超过 1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。 那么情况有多糟糕？ 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了，说明这座桥基本上已经快承受不了，还有超出桥负载两倍多的车辆正在等待。
上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。
和收过桥费的管理员一样，你当然希望你的汽车（操作）不会被焦急的等待。所以，理想状态 下，都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00，但长此以往保持这 个状态，就说明会有问题，这时候你应该会很焦急。
「所以你说的理想负荷为 1.00 ？」嗯，这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70：
- * 「需要进行调查法则」：* 如果长期你的系统负载在 0.70 上下，那么你需要在事情变得更糟糕之前，花些时间了解其原因。
- * 「现在就要修复法则」：1.00 。* 如果你的服务器系统负载长期徘徊于 1.00，那么就应该马上解决这个问题。否则，你将半夜接到你上司的电话，这可不是件令人愉快的事情。
- * 「凌晨三点半锻炼身体法则」：5.00。* 如果你的服务器负载超过了 5.00 这个数字，那么你将失去你的睡眠，还得在会议中说明这情况发生的原因，总之千万不要让它发生。
哇喔，你有四个处理器的主机？那么它的负载均值在 3.00 是很正常的。
在多处理器系统中，负载均值是基于内核的数量决定的。以 100% 负载计算，1.00 表示单个处理器，而 2.00 则说明有两个双处理器，那么 4.00 就说明主机具有四个处理器。
回到我们上面有关车辆过桥的比喻。1.00 我说过是「一条单车道的道路」。那么在单车道 1.00 情况中，说明这桥梁已经被车塞满了。而在双处理器系统中，这意味着多出了一倍的 负载，也就是说还有 50% 的剩余系统资源 -- 因为还有另外条车道可以通行。
所以，单处理器已经在负载的情况下，双处理器的负载满额的情况是 2.00，它还有一倍的资源可以利用。
多核与多处理器先脱离下主题，我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解，一台主 机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多，不同数量的缓存、处理器的频率等因素都可能造成性能的差异。
但即便这些因素造成的实际性能稍有不同，其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则：
- 「有多少核心即为有多少负荷」法则： 在多核处理中，你的系统均值不应该高于处理器核心的总数量。
- 「核心的核心」法则： 核心分布在分别几个单个物理处理中并不重要，其实两颗四核的处理器 等于 四个双核处理器 等于 八个单处理器。所以，它应该有八个处理器内核。
让我们再来看看 uptime 的输出
~ $ uptime23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36
这是个双核处理器，从结果也说明有很多的空闲资源。实际情况是即便它的峰值会到 1.7，我也从来没有考虑过它的负载问题。
那么，怎么会有三个数字的确让人困扰。我们知道，0.65、0.42、0.36 分别说明上一分钟、最后五分钟以及最后十五分钟的系统负载均值。那么这又带来了一个问题：
- 我们以哪个数字为准？一分钟？五分钟？还是十五分钟？ *
其实对于这些数字我们已经谈论了很多，我认为你应该着眼于五分钟或者十五分钟的平均数 值。坦白讲，如果前一分钟的负载情况是 1.00，那么仍可以说明认定服务器情况还是正常的。 但是如果十五分钟的数值仍然保持在 1.00，那么就值得注意了（根据我的经验，这时候你应 该增加的处理器数量了）。
- 那么我如何得知我的系统装备了多少核心的处理器？ *
在 Linux 下，可以使用
cat /proc/cpuinfo获取你系统上的每个处理器的信息。如果你只想得到数字，那么就使用下面的命令：
grep 'model name' /proc/cpuinfo | wc -l转自：http://www.gracecode.com/posts/2973.html
本文链接