is the tickless kernel now the standard?
given that ubuntu ships with the kernel configured for tickless behaviour, and that RHEL6 also ships tickless, is it safe to say that tickless is now the standard configuration? is there a compelling reason to *not* run tickless with the latest 2.6 kernels? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: is the tickless kernel now the standard?
On Sun, 15 May 2011, Greg KH wrote:
On Sun, May 15, 2011 at 12:41:30PM -0400, Robert P. J. Day wrote:
given that ubuntu ships with the kernel configured for tickless
behaviour, and that RHEL6 also ships tickless, is it safe to say that
tickless is now the standard configuration? is there a compelling
reason to *not* run tickless with the latest 2.6 kernels?
Yes it is the standard and no, there is not any reason to not enable
it. Unless you like burning extra power for no reason.
ok, good to know. i assume, then, that it's fairly pointless to use
the value of jiffies for anything that requires even moderate
accuracy. i was poking around the timer code, and i can see this in
kernel/time/timekeeping.c:
/*
* The 64-bit jiffies value is not atomic - you MUST NOT read it
* without sampling the sequence number in xtime_lock.
* jiffies is defined in the linker script...
*/
void do_timer(unsigned long ticks)
{
jiffies_64 += ticks;
update_wall_time();
calc_global_load(ticks);
}
so obviously jiffies_64 can jump up an arbitrary number of ticks on
any call. i can also see where that routine is called in
kernel/time/tick-sched.c:
static void tick_do_update_jiffies64(ktime_t now)
{
unsigned long ticks = 0;
ktime_t delta;
... snip ...
}
do_timer(++ticks);
etc, etc.
i may read more just to fill out the missing bits, unless there's a
decent online explanation of how jiffies works in the context of
tickless kernels. thanks.
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
___
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: is the tickless kernel now the standard?
On Sun, May 15, 2011 at 01:48:43PM -0400, Robert P. J. Day wrote: On Sun, 15 May 2011, Greg KH wrote: On Sun, May 15, 2011 at 12:41:30PM -0400, Robert P. J. Day wrote: given that ubuntu ships with the kernel configured for tickless behaviour, and that RHEL6 also ships tickless, is it safe to say that tickless is now the standard configuration? is there a compelling reason to *not* run tickless with the latest 2.6 kernels? Yes it is the standard and no, there is not any reason to not enable it. Unless you like burning extra power for no reason. ok, good to know. i assume, then, that it's fairly pointless to use the value of jiffies for anything that requires even moderate accuracy. i was poking around the timer code, and i can see this in kernel/time/timekeeping.c: No, never access jiffies directly, use the correct delay and timer functions instead, they will handle things properly. And that's the way to get correct accuracy if you need it. thanks, greg k-h ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
should drivers avoid the use of in_atomic()?
perusing some timer-related kernel stuff and i ran across this in include/linux/hardirq.h: /* * Are we running in atomic context? WARNING: this macro cannot * always detect atomic context; in particular, it cannot know about * held spinlocks in non-preemptible kernels. Thus it should not be * used in the general case to determine whether sleeping is possible. * Do not use in_atomic() in driver code. */ #define in_atomic() ((preempt_count() ~PREEMPT_ACTIVE) != PREEMPT_INATOMIC_BASE) but a quick check shows a sprinkling of in_atomic() checks in the drivers/ directory. is that admonition overly strict? or what? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How vmlinux is recognized?
On Fri, May 13, 2011 at 7:12 AM, Dave Hylands dhyla...@gmail.com wrote: Hi Vikram, ...snip... So when compiling the kernel, what is the purpose of the other files(mentioned below) linux-2.6/vmlinux - ELF executable, not stripped linux-2.6/arch/x86/boot/vmlinux.bin - Raw binary (Guess this is the one which is inside the bzImage) linux-2.6/arch/x86/boot/compressed/vmlinux.bin - ELF executable, stripped linux-2.6/arch/x86/boot/compressed/vmlinux - ELF executable, not stripped Take luca's email and start at the bottom working towards the top. linux-2.6/vmlinux is the output of the linker. As such, it is an ELF file. A binary is then extracted from this to create arch/x86/boot/compressed/vmlinux.bin This binary is then compressed to produce arch/x86/boot/compressed/vmlinux.bin.gz This gzipped binary is then converted into an object file (which just contains the gzipped data) but now we're back to having an ELF file called arch/x86/boot/compressed/piggy.o The linker then compiles a decompressor (misc.o) and piggy.o together to produce arch/x86/boot/compressed/vmlinux (an ELF file). objcopy is used again to convert this ELF into a binary: arch/x86/boot/compressed/vmlinux arch/x86/boot/vmlinux.bin Finally, the binary is compressed to produce bzImage. So what you get is a compressed binary which contains a decompressor and another compressed binary, this inner compressed binary being the kernel. GRUB loads bzImage into memory and decompresses it and then executes the resulting binary. This binary starts with a decompressor which then decompresses the kernel, and executes the resulting binary. This binary may relocate itself (probably depends on the architecture) to a different spot in memory, and then runs. The kernel is now running. Thanks for the detailed explanation. Clarified. :) - Thanks Vikram ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: How vmlinux is recognized?
I loved this reply...can I annotate it with references to the linux kernel sources? On Fri, May 13, 2011 at 9:42 AM, Dave Hylands dhyla...@gmail.com wrote: Hi Vikram, ...snip... So when compiling the kernel, what is the purpose of the other files(mentioned below) linux-2.6/vmlinux - ELF executable, not stripped linux-2.6/arch/x86/boot/vmlinux.bin - Raw binary (Guess this is the one which is inside the bzImage) linux-2.6/arch/x86/boot/compressed/vmlinux.bin - ELF executable, stripped linux-2.6/arch/x86/boot/compressed/vmlinux - ELF executable, not stripped Take luca's email and start at the bottom working towards the top. linux-2.6/vmlinux is the output of the linker. As such, it is an ELF file. A binary is then extracted from this to create arch/x86/boot/compressed/vmlinux.bin yes: See ./arch/x86/boot/Makefile This binary is then compressed to produce arch/x86/boot/compressed/vmlinux.bin.gz See ./arch/x86/boot/compressed/Makefile This gzipped binary is then converted into an object file (which just contains the gzipped data) but now we're back to having an ELF file ./arch/x86/boot/compressed/mkpiggy.c is compiled into a commandline binary - mkpiggy which will generate the piggy.o. called arch/x86/boot/compressed/piggy.o The linker then compiles a decompressor (misc.o) and piggy.o together Yes, the routine is called decompress_kernel, residing inside ./arch/x86/boot/compressed/misc.c. And this routine is called from ./arch/x86/boot/compressed/head_32.S (or head_64.S) and at runtime, the gzipped data is decompressed and immediately jumped into (perhaps after some relocation if needed): /* * Do the decompression, and jump to the new kernel.. */ lealz_extract_offset_negative(%ebx), %ebp /* push arguments for decompress_kernel: */ pushl %ebp/* output address */ pushl $z_input_len/* input_len */ lealinput_data(%ebx), %eax pushl %eax/* input_data */ lealboot_heap(%ebx), %eax pushl %eax/* heap area */ pushl %esi/* real mode pointer */ calldecompress_kernel addl$20, %esp to produce arch/x86/boot/compressed/vmlinux (an ELF file). objcopy is used again to convert this ELF into a binary: arch/x86/boot/compressed/vmlinux arch/x86/boot/vmlinux.bin Finally, the binary is compressed to produce bzImage. Inside arch/x86/boot/Makefile: Creating the vmlinux.bin from vmlinux via objcopy (note that this operation will throw all relocation information): $(obj)/vmlinux.bin: $(obj)/compressed/vmlinux FORCE $(call if_changed,objcopy) And then packing together linearly to form the bzImage (output from make): make -f scripts/Makefile.build obj=arch/x86/boot arch/x86/boot/bzImage make -f scripts/Makefile.build obj=arch/x86/boot/compressed arch/x86/boot/compressed/vmlinux arch/x86/boot/tools/build arch/x86/boot/setup.bin arch/x86/boot/vmlinux.bin CURRENT arch/x86/boot/bzImage So what you get is a compressed binary which contains a decompressor and another compressed binary, this inner compressed binary being the kernel. GRUB loads bzImage into memory and decompresses it and then executes the resulting binary. To be more precise, grub will load bzImage and jump into the startup_32 function located in arch/x86/boot/compressed/head_32.S at the following fixed address (from source code): /* * head.S contains the 32-bit startup code. * * NOTE!!! Startup happens at absolute address 0x1000, which is also where * the page directory will exist. The startup code will be overwritten by * the page directory. [According to comments etc elsewhere on a compressed * kernel it will end up at 0x1000 + 1Mb I hope so as I assume this. - AC] * * Page 0 is deliberately kept safe, since System Management Mode code in * laptops may need to access the BIOS data stored there. This is also * useful for future device drivers that either access the BIOS via VM86 * mode. */ More info: http://books.google.com/books?id=e8BbHxVhzFACpg=PA1224lpg=PA1224dq=grub+head_32.Ssource=blots=0MSdKwBoM6sig=2RyEpprl25zueiqi332TQHLIj0Ehl=enei=y5vQTY7eBNDNrQeI3bTCCgsa=Xoi=book_resultct=resultresnum=3ved=0CCkQ6AEwAg#v=onepageq=grub%20head_32.Sf=false This binary starts with a decompressor which then decompresses the kernel, and executes the resulting binary. This binary may relocate itself (probably depends on the architecture) to a different spot in memory, and then runs. The kernel is now running. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com ___ K -- Regards, Peter Teoh ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
asm/types.h question
Hi all, The types listed in asm/types.h __u8, __u16, __u32 and such... ¿ are these types the same as the ones for the kernel ? ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: is the tickless kernel now the standard?
Hi! On 11:01 Sun 15 May , Greg KH wrote: On Sun, May 15, 2011 at 01:48:43PM -0400, Robert P. J. Day wrote: ... ok, good to know. i assume, then, that it's fairly pointless to use the value of jiffies for anything that requires even moderate accuracy. i was poking around the timer code, and i can see this in kernel/time/timekeeping.c: No, never access jiffies directly, use the correct delay and timer functions instead, they will handle things properly. And that's the way to get correct accuracy if you need it. When switchint from jiffies+timers to hrtimers what should be used as a monotonic time source? ktime_get()? What am I supposed to do if timekeeping_valid_for_hres() returns 0? Can I ignore this? What does it mean this highres timer are not available during system startup? Are they running with lower resolution or not at all? -Michi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: is the tickless kernel now the standard?
On 06:42 Mon 16 May , Michael Blizek wrote: ... What does it mean this highres timer are not available during system startup? Are they running with lower resolution or not at all? Sorry, I should have read to the end... From Documentation/timers/highres.txt Up to the point where hrtimers are initialized, the system works in the usual low resolution periodic mode. -Michi ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: kernel BUG while reading from SPI into static buffer
On 13 May 2011 20:02, Mulyadi Santosa mulyadi.sant...@gmail.com wrote: Feel free to try to observer whether this statement is correct or not... and you should check the address of buffer when declared as static I guess I did, and here's the result: Local Buffer - 0xc3a61edd Static Buffer - 0xbf03eac1 So they indeed seem to be way apart in memory :). On 13 May 2011 20:38, Greg KH g...@kroah.com wrote: Don't statically allocate memory for spi, you need to dynamically allocate it with 'kmalloc'. The fact that the first time didn't crash for you was just lucky. I'm guessing you say this because static variables are not in DMA capable memory. But how exactly do we figure out which part of memory is DMA-capable and which isn't? Also, is this a restriction imposed by the kernel or by the hardware? Thanks Regards, Felix. ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
