# About processor type and features

## fangwen

Though having compiled my kernel for a lot of times, I still have many confusions with it. I read this on Pappy's kernel seeds, *Quote:*   

> Timer frequency should be limited to 300Hz for CPU's with more than two cores. Timer frequency should be limited to 1000Hz for dual core processors. The reason for this is the timer frequencies have an additive effect: each core runs at the frequency given, and that can increase the internal frequency over 3000Hz. That can cause boot failure, driver failure, and erratic operation, depending on the system.

 What is the difference between "two cores" and "dual core"? I have a laptop with an Intel core i3 cpu, which category does it fall into?

And one more question about the kernel preemption mode, which one should I choose for my laptop, Desktop or Low-Latency Desktop?

----------

## DaggyStyle

 *fangwen wrote:*   

> Though having compiled my kernel for a lot of times, I still have many confusions with it. I read this on Pappy's kernel seeds, *Quote:*   Timer frequency should be limited to 300Hz for CPU's with more than two cores. Timer frequency should be limited to 1000Hz for dual core processors. The reason for this is the timer frequencies have an additive effect: each core runs at the frequency given, and that can increase the internal frequency over 3000Hz. That can cause boot failure, driver failure, and erratic operation, depending on the system. What is the difference between "two cores" and "dual core"? I have a laptop with an Intel core i3 cpu, which category does it fall into?
> 
> And one more question about the kernel preemption mode, which one should I choose for my laptop, Desktop or Low-Latency Desktop?

 

imho, dual core is two physical cores on the same cpu (c2d), two cores and logical cores.

----------

## aCOSwt

Language barrier probably but I do not understand extactly what papy means.

1/ Formally speaking, the processors do not run at the frequency of the timer. They do actually run at the frequency of their own clock. I mean a not under/over clocked X Ghz processor runs at X Ghz.

2/ My understanding is that the timer frequency has more to do with the scheduler. When a thread (a part of a given task) is elected by the scheduler to run, that is to say that one core will be running the associated code, the scheduler grants to this thread an integer multiple of the time given by the timer frequency.

That is also to say that (if no other interrupt occurs during the time and if the code is not blocked waiting for some event) the scheduler will not preempt this thread for the above granted period of time.

3/ As a consequence of this, the lower this timer frequency is, the greater the time granted above is. As Linux is not formally speaking a real time operating system, If another task you would want more important needs to run, it will have to wait for the time to be elapsed and the other thread to be preempted.

Conversely, the higher this timer frequency is, the lower the time granted above is => The system will be more reactive, tasks with higher priorities will have the chance to run more often.

But there is a drawback in that each time an interrupt occurs, the system must achieve some administrative tasks (saving context (registers, stack)...) consuming time per se.

=> You want a very reactive system (pseudo-real time) for process supervision for example or audio recording => Increase the time frequency to its maximum. In this case, you definitely want the low latency desktop mode kernel preemption as well.

=> You want a system for file / http server, running databases or a desktop for playing, standard office work... => Decrease this value to the minimum and opt for the desktop kernel preemption mode.

The kernel preemption mode is linked to the fact that contrarily to pure shared-time OSes in which only user threads can be preempted, Linux can also preempt user tasks working in kernel mode, that is to say a user task executing a system call.

Depending on the kernel preemption mode chosen, the conditions for preempting such code are more or less restricted.

The less it is restricted (low latency desktop) the more reactive your system will be to external events.

----------

## phajdan.jr

 *fangwen wrote:*   

> What is the difference between "two cores" and "dual core"?

 

If I'm reading this correctly, it's more like "more than two cores" vs "dual core" (i.e. "two cores"), which can also be written like "> 2" and "= 2".

----------

## fangwen

 *phajdan.jr wrote:*   

> If I'm reading this correctly, it's more like "more than two cores" vs "dual core" (i.e. "two cores"), which can also be written like "> 2" and "= 2".

 Well, I guess I made a mistake.  :Smile: 

A further quesiton, with hyper threading support, I can see 4 processors on my computer, should the two logical processors also count as "cores"?

And, special thanks to aCOSwt, you helped me understand the relationship between timer frequency and kernel preemption. When I look into the kernel help, I found that there is a really good guide about preemption and timer frequency. I decide to use Desktop preemption mode and set the timer frequency to 1000HZ (It is the preferred choice according to the kernel help).

----------

## depontius

 *fangwen wrote:*   

> 
> 
> A further quesiton, with hyper threading support, I can see 4 processors on my computer, should the two logical processors also count as "cores"?
> 
> 

 

The best answer is "it depends."  I'm running on a Core I7 Quad at work, and it shows up as 8 processors.  On select workloads I have managed to see this system 95% utilized - in other words it's really computing as if it has 8 cores.  Those workloads are VLSI CAD verification jobs that were designed to run on multiple cores, however.  On a more general workload I've been very happy to see "65% utilization of 8 cores".  In that sense, HT is giving me about a 10-15% throughput boost.  If HT were completely worthless I'd see 50% utilization of 8 cores.  I've also heard that for some workloads HT can actually hurt throughput.  For me it's a mild to big win, depending on the specific job mix.

----------

## eccerr0r

I think the biggest thing I saw with HT:

I was experimenting HT on my Pentium4 (Prescott).  HT enabled kernel, so I see two threads.

Was using Distributed.net RC5-64 as the benchmark.

I was getting something like 9.1MKeys/sec when running one instance(single threaded).  But I tried running two threads just to see what it would do.  I found that each thread was doing around 4.8 MKeys/sec... slower...

but is it?

4.8+4.8=9.6Mkeys/sec.  Just got another 500KKeys/sec using HT, and thus it's a win.

Of course this is dependent on what you're running... just so happens that RC5-64 seems to be able to take advantage of HT.  I enable HT on my Atom N270 now for this reason but I haven't benchmarked it for how much it increases overall speed...

but back to the original posting... I don't get it.  With tickless kernels interrupts don't quite make sense...  Then again yes, if the workload does try to bang on the core at the full 1KHz rate there will be some resource contention if they all need off chip resources, but if it's written right, why would it cause erratic operation?

----------

## depontius

I believe that "tickless" might be a little bit of a misnomer, and is at least a little complicated.  The tickless kernels actually came from Linux on S390 mainframes, where they may have been running thousands of virtual images.  With a conventional ticking kernel, each image was ticking, and that really added up, for the physical machine.  Tickless really means that the kernel only ticks as much as it needs to, and manages to quit ticking when it doesn't.  The kernel needs to tick when there are multiple jobs on the runqueue, and it's necessary to parcel out the CPU time between them in some sort of "fair" way.  In other words, the "tick" is used to interrupt the running job so that the schedular can hand the CPU off to a different job.

----------

## depontius

In a fairly timely fashion, today Phoronix has an article about further tickless work on the Linux kernel.

http://www.phoronix.com/scan.php?page=news_item&px=MTA0NDc

----------

