From xose.vazquez at gmail.com Sat Oct 3 21:31:07 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Sat, 03 Oct 2009 23:31:07 +0200 Subject: update kernel in liveusb In-Reply-To: <4ABE3EE6.5030404@diffingo.com> References: <4AACF390.6000506@gmail.com> <4ABE3EE6.5030404@diffingo.com> Message-ID: <4AC7C29B.6080101@gmail.com> On 09/26/2009 06:18 PM, Stewart Adam wrote: > On 2009/09/13 9:28 AM, Xose Vazquez Perez wrote: >> hi, >> >> is there a _easy and fast_ way to update the kernel in the >> liveusb distribution ? > You can find out more information about this process by taking at the > tools in the livecd-tools repository on Fedora Hosted... But in short it > seems this goes into /etc/sysconfig/mkinitrd: I call this the hard and long way ;-) > LIVEOS=yes > PROBE=no > MODULES+="squashfs ext4 ext3 ext2 vfat msdos " > MODULES+="sr_mod sd_mod ide-cd cdrom " > MODULES+="ehci_hcd uhci_hcd ohci_hcd " > MODULES+="usb_storage usbhid " > MODULES+="firewire-sbp2 firewire-ohci " > MODULES+="sbp2 ohci1394 ieee1394 " > MODULES+="mmc_block sdhci sdhci-pci " > MODULES+="pata_pcmcia " > MODULES+="=ata sym53c8xx aic7xxx mptsas udf" > > I'm not sure about the =ata part, that's what seems to happen when you > follow the script's logic in imgcreate/live.py. Give it a try, but if > mkinitrd fails to work then try removing the "=" from the beginning of > "=ata" or even just remove "=ata" completely. > Original initrd brings more modules: aic7xxx ata_generic crc-itu-t drm ext2 fat firewire-core firewire-ohci firewire-sbp2 i2c-algo-bit i2c-core i810 i830 i915 mga mmc_block mmc_core mptbase mptsas mptscsih msdos nouveau output pata_acpi pata_ali pata_amd pata_artop pata_atiixp pata_cmd640 pata_cmd64x pata_cs5520 pata_cs5530 pata_cs5535 pata_cs5536 pata_cypress pata_efar pata_hpt366 pata_hpt37x pata_hpt3x2n pata_hpt3x3 pata_it8213 pata_it821x pata_jmicron pata_marvell pata_mpiix pata_netcell pata_ninja32 pata_ns87410 pata_ns87415 pata_oldpiix pata_optidma pata_opti pata_pcmcia pata_pdc2027x pata_pdc202xx_old pata_qdi pata_sch pata_serverworks pata_sil680 pata_sis pata_sl82c105 pata_triflex pata_via r128 radeon sata_inic162x sata_mv sata_nv sata_promise sata_qstor sata_sil24 sata_sil sata_sis sata_svw sata_sx4 sata_uli sata_via sata_vsc savage scsi_transport_sas scsi_transport_spi sdhci sdhci-pci sis squashfs sym53c8xx tdfx udf usb-storage vfat via video I get the list doing: $ cp initrd0.img img.gz ; gunzip img.gz $ mkdir d ; cd d ; cpio -idv < ../img $ (for i in `find . | grep "\.ko$"`; do basename $i | sed 's/.ko//' ; done ) | sort > Once /etc/sysconfig/mkinitrd file is in place, create your new initrd > image with mkinitrd (remember if applicable to restore the system's > /etc/sysconfig/mkinitrd back). Then, copy your newly created initrd > image and kernel image (/boot/vmlinuz-$version) into the "sysconfig" > directory of the LiveUSB and change the syslinux or grub boot > configuration files appropriately (these are also in the syslinux/ > directory on the USB key). here I use mkliveinitrd. *I believe it should have a easiest way to do it.* -thanks- regards, -- ?All? muevan feroz guerra, ciegos reyes por un palmo m?s de tierra; que yo aqu? tengo por m?o cuanto abarca el mar brav?o, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y d? pecho a mi valor.? From xose.vazquez at gmail.com Sat Oct 3 21:47:41 2009 From: xose.vazquez at gmail.com (Xose Vazquez Perez) Date: Sat, 03 Oct 2009 23:47:41 +0200 Subject: [RFE] x86_64 kernel running in i386 distribution In-Reply-To: <20090913135845.GA5607@amit-x200.redhat.com> References: <4AACF7DD.1020809@gmail.com> <20090913135845.GA5607@amit-x200.redhat.com> Message-ID: <4AC7C67D.9000308@gmail.com> On 09/13/2009 03:58 PM, Amit Shah wrote: > On (Sun) Sep 13 2009 [15:47:09], Xose Vazquez Perez wrote: >> hi, >> >> would it be possible to adapt the i386 distribucion >> to run also the x86_64 kernel ? > > You can just 'yum install kernel.x86_64' and that'll work. I did it in Fedora-11_i386 and there is no x86_64 kernel package. maybe you are talking about fedora 12 ?? Time ago I installed a Fedora-10 x86_64 kernel in the Fedora_10 i386 distribution but I got troubles when yum was trying to get updates. Otherwise all was running OK. -thanks- regards, -- ?All? muevan feroz guerra, ciegos reyes por un palmo m?s de tierra; que yo aqu? tengo por m?o cuanto abarca el mar brav?o, a quien nadie impuso leyes. Y no hay playa, sea cualquiera, ni bandera de esplendor, que no sienta mi derecho y d? pecho a mi valor.? From drago01 at gmail.com Sun Oct 4 07:35:59 2009 From: drago01 at gmail.com (drago01) Date: Sun, 4 Oct 2009 09:35:59 +0200 Subject: [RFE] x86_64 kernel running in i386 distribution In-Reply-To: <4AACF7DD.1020809@gmail.com> References: <4AACF7DD.1020809@gmail.com> Message-ID: 2009/9/13 Xose Vazquez Perez : > hi, > > would it be possible to adapt the i386 distribucion > to run also the x86_64 kernel ? Why not just use a x86_64 userspace and kernel i.e x86_64 distro ? From amitshah at gmx.net Mon Oct 5 08:33:09 2009 From: amitshah at gmx.net (Amit Shah) Date: Mon, 5 Oct 2009 14:03:09 +0530 Subject: [RFE] x86_64 kernel running in i386 distribution In-Reply-To: <4AC7C67D.9000308@gmail.com> References: <4AACF7DD.1020809@gmail.com> <20090913135845.GA5607@amit-x200.redhat.com> <4AC7C67D.9000308@gmail.com> Message-ID: <20091005083309.GB18005@amit-x200.redhat.com> On (Sat) Oct 03 2009 [23:47:41], Xose Vazquez Perez wrote: > On 09/13/2009 03:58 PM, Amit Shah wrote: > > > On (Sun) Sep 13 2009 [15:47:09], Xose Vazquez Perez wrote: > >> hi, > >> > >> would it be possible to adapt the i386 distribucion > >> to run also the x86_64 kernel ? > > > > You can just 'yum install kernel.x86_64' and that'll work. > > I did it in Fedora-11_i386 and there is no x86_64 kernel package. Maybe you need to add the x86_64 repos to your yum config. Amit -- http://log.amitshah.net/ From srostedt at redhat.com Thu Oct 8 23:17:58 2009 From: srostedt at redhat.com (Steven Rostedt) Date: Thu, 08 Oct 2009 19:17:58 -0400 Subject: Critical patches for the kernel Message-ID: <1255043878.24454.81.camel@localhost.localdomain> FYI, Linus just pulled in two patches that are critical for ftrace. These are needed for every kernel since 2.6.28. GregKH has already been informed and will be pulling them into the stable releases. 3279ba37db5d65c4ab0dcdee3b211ccb85bb563f and e7247a15ff3bbdab0a8b402dffa1171e5c05a8e0 Please make sure they are applied to the Fedora kernel. Thanks, -- Steve From prarit at redhat.com Mon Oct 12 15:54:33 2009 From: prarit at redhat.com (Prarit Bhargava) Date: Mon, 12 Oct 2009 11:54:33 -0400 Subject: [Fedora PATCH] Improve Resource Counter Scalability Message-ID: <20091012155220.24701.27938.sendpatchset@prarit.bos.redhat.com> This patch was sent to me by Balbir Singh, cc'd, who worked on the original patch. The patch results in a massive increase in performance on a 64p/32G system. The patch was successfully compiled and tested by me on fedora-latest. >From the upstream commit: "Data from Prarit (kernel compile with make -j64 on a 64 CPU/32G machine) For a single run Without patch real 27m8.988s user 87m24.916s sys 382m6.037s With patch real 4m18.607s user 84m58.943s sys 50m52.682s With config turned off real 4m54.972s user 90m13.456s sys 50m19.711s NOTE: The data looks counterintuitive due to the increased performance with the patch, even over the config being turned off. We probably need more runs, but so far all testing has shown that the patches definitely help." ------------------------------------------------------------------------------- Backport 0c3e73e84fe3f64cf1c2e8bb4e91e8901cbcdc38 From: Balbir Singh (memcg: improve resource counter scalability) to 2.6.31. It is a very useful patch for non-users of memory control group as it reduces the overhead quite significantly. Signed-off-by: Balbir Singh --- mm/memcontrol.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++--------- 1 files changed, 106 insertions(+), 21 deletions(-) diff --git a/mm/memcontrol.c b/mm/memcontrol.c index fd4529d..4821be0 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -43,6 +43,7 @@ struct cgroup_subsys mem_cgroup_subsys __read_mostly; #define MEM_CGROUP_RECLAIM_RETRIES 5 +struct mem_cgroup *root_mem_cgroup __read_mostly; #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP /* Turned on only when memory cgroup is enabled && really_do_swap_account = 1 */ @@ -66,6 +67,7 @@ enum mem_cgroup_stat_index { MEM_CGROUP_STAT_MAPPED_FILE, /* # of pages charged as file rss */ MEM_CGROUP_STAT_PGPGIN_COUNT, /* # of pages paged in */ MEM_CGROUP_STAT_PGPGOUT_COUNT, /* # of pages paged out */ + MEM_CGROUP_STAT_SWAPOUT, /* # of pages, swapped out */ MEM_CGROUP_STAT_NSTATS, }; @@ -219,11 +221,24 @@ static void mem_cgroup_get(struct mem_cgroup *mem); static void mem_cgroup_put(struct mem_cgroup *mem); static struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *mem); +static void mem_cgroup_swap_statistics(struct mem_cgroup *mem, + bool charge) +{ + int val = (charge) ? 1 : -1; + struct mem_cgroup_stat *stat = &mem->stat; + struct mem_cgroup_stat_cpu *cpustat; + int cpu = get_cpu(); + + cpustat = &stat->cpustat[cpu]; + __mem_cgroup_stat_add_safe(cpustat, MEM_CGROUP_STAT_SWAPOUT, val); + put_cpu(); +} + static void mem_cgroup_charge_statistics(struct mem_cgroup *mem, struct page_cgroup *pc, bool charge) { - int val = (charge)? 1 : -1; + int val = (charge) ? 1 : -1; struct mem_cgroup_stat *stat = &mem->stat; struct mem_cgroup_stat_cpu *cpustat; int cpu = get_cpu(); @@ -354,6 +369,11 @@ static int mem_cgroup_walk_tree(struct mem_cgroup *root, void *data, return ret; } +static inline bool mem_cgroup_is_root(struct mem_cgroup *mem) +{ + return (mem == root_mem_cgroup); +} + /* * Following LRU functions are allowed to be used without PCG_LOCK. * Operations are called by routine of global LRU independently from memcg. @@ -996,9 +1016,11 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm, VM_BUG_ON(css_is_removed(&mem->css)); while (1) { - int ret; + int ret = 0; bool noswap = false; + if (mem_cgroup_is_root(mem)) + goto done; ret = res_counter_charge(&mem->res, PAGE_SIZE, &fail_res); if (likely(!ret)) { if (!do_swap_account) @@ -1046,6 +1068,7 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm, goto nomem; } } +done: return 0; nomem: css_put(&mem->css); @@ -1119,9 +1142,11 @@ static void __mem_cgroup_commit_charge(struct mem_cgroup *mem, lock_page_cgroup(pc); if (unlikely(PageCgroupUsed(pc))) { unlock_page_cgroup(pc); - res_counter_uncharge(&mem->res, PAGE_SIZE); - if (do_swap_account) - res_counter_uncharge(&mem->memsw, PAGE_SIZE); + if (!mem_cgroup_is_root(mem)) { + res_counter_uncharge(&mem->res, PAGE_SIZE); + if (do_swap_account) + res_counter_uncharge(&mem->memsw, PAGE_SIZE); + } css_put(&mem->css); return; } @@ -1178,7 +1203,8 @@ static int mem_cgroup_move_account(struct page_cgroup *pc, if (pc->mem_cgroup != from) goto out; - res_counter_uncharge(&from->res, PAGE_SIZE); + if (!mem_cgroup_is_root(from)) + res_counter_uncharge(&from->res, PAGE_SIZE); mem_cgroup_charge_statistics(from, pc, false); page = pc->page; @@ -1197,7 +1223,7 @@ static int mem_cgroup_move_account(struct page_cgroup *pc, 1); } - if (do_swap_account) + if (do_swap_account && !mem_cgroup_is_root(from)) res_counter_uncharge(&from->memsw, PAGE_SIZE); css_put(&from->css); @@ -1268,9 +1294,11 @@ uncharge: /* drop extra refcnt by try_charge() */ css_put(&parent->css); /* uncharge if move fails */ - res_counter_uncharge(&parent->res, PAGE_SIZE); - if (do_swap_account) - res_counter_uncharge(&parent->memsw, PAGE_SIZE); + if (!mem_cgroup_is_root(parent)) { + res_counter_uncharge(&parent->res, PAGE_SIZE); + if (do_swap_account) + res_counter_uncharge(&parent->memsw, PAGE_SIZE); + } return ret; } @@ -1459,7 +1487,9 @@ __mem_cgroup_commit_charge_swapin(struct page *page, struct mem_cgroup *ptr, * This recorded memcg can be obsolete one. So, avoid * calling css_tryget */ - res_counter_uncharge(&memcg->memsw, PAGE_SIZE); + if (!mem_cgroup_is_root(memcg)) + res_counter_uncharge(&memcg->memsw, PAGE_SIZE); + mem_cgroup_swap_statistics(memcg, false); mem_cgroup_put(memcg); } rcu_read_unlock(); @@ -1484,9 +1514,11 @@ void mem_cgroup_cancel_charge_swapin(struct mem_cgroup *mem) return; if (!mem) return; - res_counter_uncharge(&mem->res, PAGE_SIZE); - if (do_swap_account) - res_counter_uncharge(&mem->memsw, PAGE_SIZE); + if (!mem_cgroup_is_root(mem)) { + res_counter_uncharge(&mem->res, PAGE_SIZE); + if (do_swap_account) + res_counter_uncharge(&mem->memsw, PAGE_SIZE); + } css_put(&mem->css); } @@ -1538,9 +1570,14 @@ __mem_cgroup_uncharge_common(struct page *page, enum charge_type ctype) break; } - res_counter_uncharge(&mem->res, PAGE_SIZE); - if (do_swap_account && (ctype != MEM_CGROUP_CHARGE_TYPE_SWAPOUT)) - res_counter_uncharge(&mem->memsw, PAGE_SIZE); + if (!mem_cgroup_is_root(mem)) { + res_counter_uncharge(&mem->res, PAGE_SIZE); + if (do_swap_account && + (ctype != MEM_CGROUP_CHARGE_TYPE_SWAPOUT)) + res_counter_uncharge(&mem->memsw, PAGE_SIZE); + } + if (ctype == MEM_CGROUP_CHARGE_TYPE_SWAPOUT) + mem_cgroup_swap_statistics(mem, true); mem_cgroup_charge_statistics(mem, pc, false); ClearPageCgroupUsed(pc); @@ -1629,7 +1666,9 @@ void mem_cgroup_uncharge_swap(swp_entry_t ent) * We uncharge this because swap is freed. * This memcg can be obsolete one. We avoid calling css_tryget */ - res_counter_uncharge(&memcg->memsw, PAGE_SIZE); + if (!mem_cgroup_is_root(memcg)) + res_counter_uncharge(&memcg->memsw, PAGE_SIZE); + mem_cgroup_swap_statistics(memcg, false); mem_cgroup_put(memcg); } rcu_read_unlock(); @@ -2046,20 +2085,64 @@ static int mem_cgroup_hierarchy_write(struct cgroup *cont, struct cftype *cft, return retval; } +struct mem_cgroup_idx_data { + s64 val; + enum mem_cgroup_stat_index idx; +}; + +static int +mem_cgroup_get_idx_stat(struct mem_cgroup *mem, void *data) +{ + struct mem_cgroup_idx_data *d = data; + d->val += mem_cgroup_read_stat(&mem->stat, d->idx); + return 0; +} + +static void +mem_cgroup_get_recursive_idx_stat(struct mem_cgroup *mem, + enum mem_cgroup_stat_index idx, s64 *val) +{ + struct mem_cgroup_idx_data d; + d.idx = idx; + d.val = 0; + mem_cgroup_walk_tree(mem, &d, mem_cgroup_get_idx_stat); + *val = d.val; +} + static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft) { struct mem_cgroup *mem = mem_cgroup_from_cont(cont); - u64 val = 0; + u64 idx_val, val; int type, name; type = MEMFILE_TYPE(cft->private); name = MEMFILE_ATTR(cft->private); switch (type) { case _MEM: - val = res_counter_read_u64(&mem->res, name); + if (name == RES_USAGE && mem_cgroup_is_root(mem)) { + mem_cgroup_get_recursive_idx_stat(mem, + MEM_CGROUP_STAT_CACHE, &idx_val); + val = idx_val; + mem_cgroup_get_recursive_idx_stat(mem, + MEM_CGROUP_STAT_RSS, &idx_val); + val += idx_val; + val <<= PAGE_SHIFT; + } else + val = res_counter_read_u64(&mem->res, name); break; case _MEMSWAP: - val = res_counter_read_u64(&mem->memsw, name); + if (name == RES_USAGE && mem_cgroup_is_root(mem)) { + mem_cgroup_get_recursive_idx_stat(mem, + MEM_CGROUP_STAT_CACHE, &idx_val); + val = idx_val; + mem_cgroup_get_recursive_idx_stat(mem, + MEM_CGROUP_STAT_RSS, &idx_val); + val += idx_val; + mem_cgroup_get_recursive_idx_stat(mem, + MEM_CGROUP_STAT_SWAPOUT, &idx_val); + val <<= PAGE_SHIFT; + } else + val = res_counter_read_u64(&mem->memsw, name); break; default: BUG(); @@ -2548,6 +2631,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont) /* root ? */ if (cont->parent == NULL) { enable_swap_cgroup(); + root_mem_cgroup = mem; parent = NULL; } else { parent = mem_cgroup_from_cont(cont->parent); @@ -2577,6 +2661,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont) return &mem->css; free_out: __mem_cgroup_free(mem); + root_mem_cgroup = NULL; return ERR_PTR(error); } From kamezawa.hiroyu at jp.fujitsu.com Tue Oct 13 03:21:14 2009 From: kamezawa.hiroyu at jp.fujitsu.com (KAMEZAWA Hiroyuki) Date: Tue, 13 Oct 2009 12:21:14 +0900 Subject: [Fedora PATCH] Improve Resource Counter Scalability In-Reply-To: <20091012155220.24701.27938.sendpatchset@prarit.bos.redhat.com> References: <20091012155220.24701.27938.sendpatchset@prarit.bos.redhat.com> Message-ID: <20091013122114.5cde392d.kamezawa.hiroyu@jp.fujitsu.com> On Mon, 12 Oct 2009 11:54:33 -0400 Prarit Bhargava wrote: > This patch was sent to me by Balbir Singh, cc'd, who worked on the original > patch. The patch results in a massive increase in performance on a 64p/32G > system. The patch was successfully compiled and tested by me on fedora-latest. > > >From the upstream commit: > > "Data from Prarit (kernel compile with make -j64 on a 64 > CPU/32G machine) > > For a single run > > Without patch > > real 27m8.988s > user 87m24.916s > sys 382m6.037s > > With patch > > real 4m18.607s > user 84m58.943s > sys 50m52.682s > > With config turned off > > real 4m54.972s > user 90m13.456s > sys 50m19.711s > > NOTE: The data looks counterintuitive due to the increased performance > with the patch, even over the config being turned off. We probably need > more runs, but so far all testing has shown that the patches definitely > help." > Yes, please import this change. thank you for backporting. MoreInfo: This patch itself works for "root" cgroup, which never has "limits". Patches for "child" cgroup is still under test in -mm. It's more complicated. Thanks, -Kame > ------------------------------------------------------------------------------- > > Backport 0c3e73e84fe3f64cf1c2e8bb4e91e8901cbcdc38 > > From: Balbir Singh > > (memcg: improve resource counter scalability) to 2.6.31. > It is a very useful patch for non-users of memory control > group as it reduces the overhead quite significantly. > > Signed-off-by: Balbir Singh > --- > > mm/memcontrol.c | 127 ++++++++++++++++++++++++++++++++++++++++++++++--------- > 1 files changed, 106 insertions(+), 21 deletions(-) > > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index fd4529d..4821be0 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -43,6 +43,7 @@ > > struct cgroup_subsys mem_cgroup_subsys __read_mostly; > #define MEM_CGROUP_RECLAIM_RETRIES 5 > +struct mem_cgroup *root_mem_cgroup __read_mostly; > > #ifdef CONFIG_CGROUP_MEM_RES_CTLR_SWAP > /* Turned on only when memory cgroup is enabled && really_do_swap_account = 1 */ > @@ -66,6 +67,7 @@ enum mem_cgroup_stat_index { > MEM_CGROUP_STAT_MAPPED_FILE, /* # of pages charged as file rss */ > MEM_CGROUP_STAT_PGPGIN_COUNT, /* # of pages paged in */ > MEM_CGROUP_STAT_PGPGOUT_COUNT, /* # of pages paged out */ > + MEM_CGROUP_STAT_SWAPOUT, /* # of pages, swapped out */ > > MEM_CGROUP_STAT_NSTATS, > }; > @@ -219,11 +221,24 @@ static void mem_cgroup_get(struct mem_cgroup *mem); > static void mem_cgroup_put(struct mem_cgroup *mem); > static struct mem_cgroup *parent_mem_cgroup(struct mem_cgroup *mem); > > +static void mem_cgroup_swap_statistics(struct mem_cgroup *mem, > + bool charge) > +{ > + int val = (charge) ? 1 : -1; > + struct mem_cgroup_stat *stat = &mem->stat; > + struct mem_cgroup_stat_cpu *cpustat; > + int cpu = get_cpu(); > + > + cpustat = &stat->cpustat[cpu]; > + __mem_cgroup_stat_add_safe(cpustat, MEM_CGROUP_STAT_SWAPOUT, val); > + put_cpu(); > +} > + > static void mem_cgroup_charge_statistics(struct mem_cgroup *mem, > struct page_cgroup *pc, > bool charge) > { > - int val = (charge)? 1 : -1; > + int val = (charge) ? 1 : -1; > struct mem_cgroup_stat *stat = &mem->stat; > struct mem_cgroup_stat_cpu *cpustat; > int cpu = get_cpu(); > @@ -354,6 +369,11 @@ static int mem_cgroup_walk_tree(struct mem_cgroup *root, void *data, > return ret; > } > > +static inline bool mem_cgroup_is_root(struct mem_cgroup *mem) > +{ > + return (mem == root_mem_cgroup); > +} > + > /* > * Following LRU functions are allowed to be used without PCG_LOCK. > * Operations are called by routine of global LRU independently from memcg. > @@ -996,9 +1016,11 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm, > VM_BUG_ON(css_is_removed(&mem->css)); > > while (1) { > - int ret; > + int ret = 0; > bool noswap = false; > > + if (mem_cgroup_is_root(mem)) > + goto done; > ret = res_counter_charge(&mem->res, PAGE_SIZE, &fail_res); > if (likely(!ret)) { > if (!do_swap_account) > @@ -1046,6 +1068,7 @@ static int __mem_cgroup_try_charge(struct mm_struct *mm, > goto nomem; > } > } > +done: > return 0; > nomem: > css_put(&mem->css); > @@ -1119,9 +1142,11 @@ static void __mem_cgroup_commit_charge(struct mem_cgroup *mem, > lock_page_cgroup(pc); > if (unlikely(PageCgroupUsed(pc))) { > unlock_page_cgroup(pc); > - res_counter_uncharge(&mem->res, PAGE_SIZE); > - if (do_swap_account) > - res_counter_uncharge(&mem->memsw, PAGE_SIZE); > + if (!mem_cgroup_is_root(mem)) { > + res_counter_uncharge(&mem->res, PAGE_SIZE); > + if (do_swap_account) > + res_counter_uncharge(&mem->memsw, PAGE_SIZE); > + } > css_put(&mem->css); > return; > } > @@ -1178,7 +1203,8 @@ static int mem_cgroup_move_account(struct page_cgroup *pc, > if (pc->mem_cgroup != from) > goto out; > > - res_counter_uncharge(&from->res, PAGE_SIZE); > + if (!mem_cgroup_is_root(from)) > + res_counter_uncharge(&from->res, PAGE_SIZE); > mem_cgroup_charge_statistics(from, pc, false); > > page = pc->page; > @@ -1197,7 +1223,7 @@ static int mem_cgroup_move_account(struct page_cgroup *pc, > 1); > } > > - if (do_swap_account) > + if (do_swap_account && !mem_cgroup_is_root(from)) > res_counter_uncharge(&from->memsw, PAGE_SIZE); > css_put(&from->css); > > @@ -1268,9 +1294,11 @@ uncharge: > /* drop extra refcnt by try_charge() */ > css_put(&parent->css); > /* uncharge if move fails */ > - res_counter_uncharge(&parent->res, PAGE_SIZE); > - if (do_swap_account) > - res_counter_uncharge(&parent->memsw, PAGE_SIZE); > + if (!mem_cgroup_is_root(parent)) { > + res_counter_uncharge(&parent->res, PAGE_SIZE); > + if (do_swap_account) > + res_counter_uncharge(&parent->memsw, PAGE_SIZE); > + } > return ret; > } > > @@ -1459,7 +1487,9 @@ __mem_cgroup_commit_charge_swapin(struct page *page, struct mem_cgroup *ptr, > * This recorded memcg can be obsolete one. So, avoid > * calling css_tryget > */ > - res_counter_uncharge(&memcg->memsw, PAGE_SIZE); > + if (!mem_cgroup_is_root(memcg)) > + res_counter_uncharge(&memcg->memsw, PAGE_SIZE); > + mem_cgroup_swap_statistics(memcg, false); > mem_cgroup_put(memcg); > } > rcu_read_unlock(); > @@ -1484,9 +1514,11 @@ void mem_cgroup_cancel_charge_swapin(struct mem_cgroup *mem) > return; > if (!mem) > return; > - res_counter_uncharge(&mem->res, PAGE_SIZE); > - if (do_swap_account) > - res_counter_uncharge(&mem->memsw, PAGE_SIZE); > + if (!mem_cgroup_is_root(mem)) { > + res_counter_uncharge(&mem->res, PAGE_SIZE); > + if (do_swap_account) > + res_counter_uncharge(&mem->memsw, PAGE_SIZE); > + } > css_put(&mem->css); > } > > @@ -1538,9 +1570,14 @@ __mem_cgroup_uncharge_common(struct page *page, enum charge_type ctype) > break; > } > > - res_counter_uncharge(&mem->res, PAGE_SIZE); > - if (do_swap_account && (ctype != MEM_CGROUP_CHARGE_TYPE_SWAPOUT)) > - res_counter_uncharge(&mem->memsw, PAGE_SIZE); > + if (!mem_cgroup_is_root(mem)) { > + res_counter_uncharge(&mem->res, PAGE_SIZE); > + if (do_swap_account && > + (ctype != MEM_CGROUP_CHARGE_TYPE_SWAPOUT)) > + res_counter_uncharge(&mem->memsw, PAGE_SIZE); > + } > + if (ctype == MEM_CGROUP_CHARGE_TYPE_SWAPOUT) > + mem_cgroup_swap_statistics(mem, true); > mem_cgroup_charge_statistics(mem, pc, false); > > ClearPageCgroupUsed(pc); > @@ -1629,7 +1666,9 @@ void mem_cgroup_uncharge_swap(swp_entry_t ent) > * We uncharge this because swap is freed. > * This memcg can be obsolete one. We avoid calling css_tryget > */ > - res_counter_uncharge(&memcg->memsw, PAGE_SIZE); > + if (!mem_cgroup_is_root(memcg)) > + res_counter_uncharge(&memcg->memsw, PAGE_SIZE); > + mem_cgroup_swap_statistics(memcg, false); > mem_cgroup_put(memcg); > } > rcu_read_unlock(); > @@ -2046,20 +2085,64 @@ static int mem_cgroup_hierarchy_write(struct cgroup *cont, struct cftype *cft, > return retval; > } > > +struct mem_cgroup_idx_data { > + s64 val; > + enum mem_cgroup_stat_index idx; > +}; > + > +static int > +mem_cgroup_get_idx_stat(struct mem_cgroup *mem, void *data) > +{ > + struct mem_cgroup_idx_data *d = data; > + d->val += mem_cgroup_read_stat(&mem->stat, d->idx); > + return 0; > +} > + > +static void > +mem_cgroup_get_recursive_idx_stat(struct mem_cgroup *mem, > + enum mem_cgroup_stat_index idx, s64 *val) > +{ > + struct mem_cgroup_idx_data d; > + d.idx = idx; > + d.val = 0; > + mem_cgroup_walk_tree(mem, &d, mem_cgroup_get_idx_stat); > + *val = d.val; > +} > + > static u64 mem_cgroup_read(struct cgroup *cont, struct cftype *cft) > { > struct mem_cgroup *mem = mem_cgroup_from_cont(cont); > - u64 val = 0; > + u64 idx_val, val; > int type, name; > > type = MEMFILE_TYPE(cft->private); > name = MEMFILE_ATTR(cft->private); > switch (type) { > case _MEM: > - val = res_counter_read_u64(&mem->res, name); > + if (name == RES_USAGE && mem_cgroup_is_root(mem)) { > + mem_cgroup_get_recursive_idx_stat(mem, > + MEM_CGROUP_STAT_CACHE, &idx_val); > + val = idx_val; > + mem_cgroup_get_recursive_idx_stat(mem, > + MEM_CGROUP_STAT_RSS, &idx_val); > + val += idx_val; > + val <<= PAGE_SHIFT; > + } else > + val = res_counter_read_u64(&mem->res, name); > break; > case _MEMSWAP: > - val = res_counter_read_u64(&mem->memsw, name); > + if (name == RES_USAGE && mem_cgroup_is_root(mem)) { > + mem_cgroup_get_recursive_idx_stat(mem, > + MEM_CGROUP_STAT_CACHE, &idx_val); > + val = idx_val; > + mem_cgroup_get_recursive_idx_stat(mem, > + MEM_CGROUP_STAT_RSS, &idx_val); > + val += idx_val; > + mem_cgroup_get_recursive_idx_stat(mem, > + MEM_CGROUP_STAT_SWAPOUT, &idx_val); > + val <<= PAGE_SHIFT; > + } else > + val = res_counter_read_u64(&mem->memsw, name); > break; > default: > BUG(); > @@ -2548,6 +2631,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont) > /* root ? */ > if (cont->parent == NULL) { > enable_swap_cgroup(); > + root_mem_cgroup = mem; > parent = NULL; > } else { > parent = mem_cgroup_from_cont(cont->parent); > @@ -2577,6 +2661,7 @@ mem_cgroup_create(struct cgroup_subsys *ss, struct cgroup *cont) > return &mem->css; > free_out: > __mem_cgroup_free(mem); > + root_mem_cgroup = NULL; > return ERR_PTR(error); > } > > > _______________________________________________ > Fedora-kernel-list mailing list > Fedora-kernel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-kernel-list > From wezhang at redhat.com Wed Oct 14 13:29:52 2009 From: wezhang at redhat.com (Wenming Zhang) Date: Wed, 14 Oct 2009 21:29:52 +0800 Subject: [RFE] x86_64 kernel running in i386 distribution In-Reply-To: <20091005083309.GB18005@amit-x200.redhat.com> References: <4AACF7DD.1020809@gmail.com> <20090913135845.GA5607@amit-x200.redhat.com> <4AC7C67D.9000308@gmail.com> <20091005083309.GB18005@amit-x200.redhat.com> Message-ID: <4AD5D250.2090204@redhat.com> Amit Shah wrote: > On (Sat) Oct 03 2009 [23:47:41], Xose Vazquez Perez wrote: > >> On 09/13/2009 03:58 PM, Amit Shah wrote: >> >> >>> On (Sun) Sep 13 2009 [15:47:09], Xose Vazquez Perez wrote: >>> >>>> hi, >>>> >>>> would it be possible to adapt the i386 distribucion >>>> to run also the x86_64 kernel ? >>>> >>> You can just 'yum install kernel.x86_64' and that'll work. >>> >> I did it in Fedora-11_i386 and there is no x86_64 kernel package. >> > > Maybe you need to add the x86_64 repos to your yum config. > > Amit > add x86_64 repos to yum doesn't work, because x86_64 packages couldn't be displayed by yum on i386 arch. IIRC, I did it before by using a x86_64 environment to install it to a i386 root, I meant use rpm command with '-r' argument. I think this is definitely reasonable for people who want use i386 distro for compatible reason and also want use large address space. Thanks, Wenming From Matt_Domsch at dell.com Wed Oct 21 12:09:10 2009 From: Matt_Domsch at dell.com (Domsch, Matt) Date: Wed, 21 Oct 2009 07:09:10 -0500 Subject: candidate patches for Dell laptops and netbooks Message-ID: <20091021120910.GA22609@mock.linuxdev.us.dell.com> Mario Limonciello is a Dell engineer and contributor to Ubuntu. In particular, he's been working on making sure Dell's notebooks and netbooks work with Ubuntu and therefore very recent kernels. He's run into a few fairly annoying problems, and has patches which will be carried in the Ubuntu kernel. He sent them to me, to see if Fedora 12 wants to pick up the same changes, or just wait until they all hit mainline. So I send them here, for your consideration. 1) Handling the rfkill switch on the Dell Mini {9,10,12,10v} and Inspiron 11z netbooks. These enable the wireless drivers to recognize and respond to the value of the physical rfkill switch. Without these, if Fedora is started with the rfkill switch off, the wireless driver loads but can't drive the hardware. Flipping the switch on, the driver can't respond, and wireless remains disabled. Either a manual modprobe -r; modprobe of the wireless driver, or a reboot is necessary for the driver to recognize that the rfkill switch setting is to enable wireless. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=fff16e9927ed2632b07e782ca136da5f6048861f http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=218f25dbb86d78869a9099826a5b0a64814c5d09 2) bluetooth enable/disable work from mjg. He's pushing a different approach into upstream, but this enables bluetooth + rfkill in 2.6.31ish kernels. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=c1e755f3d03c4ddc1d73e978b245921f4bce9668 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=d83364096a6fe1c3696f3cb09e40912a016e9969 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=09c7300537a8c04a2b1825520157a3618a7c9255 http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=e6cc51d2e4df23fe79e29366b822e48401753b2b 3) load the dell-wmi driver on all Dell laptops. This is a bit of a hack, as it causes the dell-wmi driver to load, even on laptops where it isn't necessary. However, 2.6.31 lacks the ability to selectively enable WMI hotkey messaging, and loading the driver on laptops where it isn't necessary does nothing (except take a bit of memory). WMI hotkeys are necessary on a growing number of laptops as they are the only method to indicate a keypress for some keys. http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=commit;h=a532d8d0f73ab13075487bb5a7110de81a2508f1 Thanks, Matt -- Matt Domsch Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux From SteveD at redhat.com Thu Oct 22 14:22:51 2009 From: SteveD at redhat.com (Steve Dickson) Date: Thu, 22 Oct 2009 10:22:51 -0400 Subject: Kernel Option Classifications Message-ID: <4AE06ABB.3060102@RedHat.com> Does anybody know if so wiki or guidelines out there that defines how kernel option should be classified? Meaning what does it really means to be 'EXPERIMENTAL' or 'DEVELOPER ONLY'. Are there any criteria that has to be met to change them or is simply up to the maintainer's discretion? tia, steved. From sds at tycho.nsa.gov Thu Oct 22 15:33:17 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 22 Oct 2009 11:33:17 -0400 Subject: CONFIG_INTEL_TXT Message-ID: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> Would it be possible to get CONFIG_INTEL_TXT enabled in the Fedora kernel x86 and x86_64 configs going forward? Thanks. -- Stephen Smalley National Security Agency From jcm at redhat.com Thu Oct 22 17:09:24 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 22 Oct 2009 18:09:24 +0100 Subject: Kernel Option Classifications In-Reply-To: <4AE06ABB.3060102@RedHat.com> References: <4AE06ABB.3060102@RedHat.com> Message-ID: <1256231364.3687.27.camel@tonnant> On Thu, 2009-10-22 at 10:22 -0400, Steve Dickson wrote: > Does anybody know if so wiki or guidelines out there > that defines how kernel option should be classified? > > Meaning what does it really means to be 'EXPERIMENTAL' or > 'DEVELOPER ONLY'. Are there any criteria that has to > be met to change them or is simply up to the maintainer's > discretion? Mostly up to their discretion. Robert P. J. Day has been doing a lot of upstream cleanup work - maybe ping him about this? Jon. From eparis at redhat.com Thu Oct 22 17:24:15 2009 From: eparis at redhat.com (Eric Paris) Date: Thu, 22 Oct 2009 13:24:15 -0400 Subject: CONFIG_INTEL_TXT In-Reply-To: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> References: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <1256232255.4443.141.camel@dhcp231-106.rdu.redhat.com> On Thu, 2009-10-22 at 11:33 -0400, Stephen Smalley wrote: > Would it be possible to get CONFIG_INTEL_TXT enabled in the Fedora > kernel x86 and x86_64 configs going forward? After some discussion with a couple of people on the Fedora kernel team on IRC they decided that we should not enable CONFIG_INTEL_TXT until it is useful for something other than a closed source binary blob which Fedora is unable to distribute. We have messaged that Fedora was unable to include the binary blob from Intel and it has been suggested that they create an open module rather than forcing Linux users to trust some part of their system security to an unknown binary blob. Hopefully you can add your weight to that discussion and help intel see the need for an open source blob. -Eric From jcm at redhat.com Thu Oct 22 17:39:53 2009 From: jcm at redhat.com (Jon Masters) Date: Thu, 22 Oct 2009 18:39:53 +0100 Subject: CONFIG_INTEL_TXT In-Reply-To: <1256232255.4443.141.camel@dhcp231-106.rdu.redhat.com> References: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> <1256232255.4443.141.camel@dhcp231-106.rdu.redhat.com> Message-ID: <1256233193.3687.40.camel@tonnant> On Thu, 2009-10-22 at 13:24 -0400, Eric Paris wrote: > On Thu, 2009-10-22 at 11:33 -0400, Stephen Smalley wrote: > > Would it be possible to get CONFIG_INTEL_TXT enabled in the Fedora > > kernel x86 and x86_64 configs going forward? > > After some discussion with a couple of people on the Fedora kernel team > on IRC they decided that we should not enable CONFIG_INTEL_TXT until it > is useful for something other than a closed source binary blob which > Fedora is unable to distribute. We have messaged that Fedora was unable > to include the binary blob from Intel and it has been suggested that > they create an open module rather than forcing Linux users to trust some > part of their system security to an unknown binary blob. Hopefully you > can add your weight to that discussion and help intel see the need for > an open source blob. Don't forget to mention the more paranoid hand-waving about removing RAM chips at runtime with liquid nitrogen after going into suspend and hax0ring. I think there will be more upstream discussion anyway. Jon. From arjan at infradead.org Fri Oct 23 15:20:00 2009 From: arjan at infradead.org (Arjan van de Ven) Date: Fri, 23 Oct 2009 08:20:00 -0700 Subject: CONFIG_INTEL_TXT In-Reply-To: <1256233193.3687.40.camel@tonnant> References: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> <1256232255.4443.141.camel@dhcp231-106.rdu.redhat.com> <1256233193.3687.40.camel@tonnant> Message-ID: <20091023082000.572614f1@infradead.org> On Thu, 22 Oct 2009 18:39:53 +0100 Jon Masters wrote: > Don't forget to mention the more paranoid hand-waving about removing > RAM chips at runtime with liquid nitrogen after going into suspend and > hax0ring. I think there will be more upstream discussion anyway. I'm sorry but this argument makes no sense whatsoever. Claiming that a feature should not be enabled because someone is talking about a mythical attack that is waaay outside the scope of what a technology wants to protect is not solid reasoning, it's fear mongering instead. -- Arjan van de Ven Intel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org From jcm at redhat.com Fri Oct 23 15:51:19 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 23 Oct 2009 16:51:19 +0100 Subject: CONFIG_INTEL_TXT In-Reply-To: <20091023082000.572614f1@infradead.org> References: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> <1256232255.4443.141.camel@dhcp231-106.rdu.redhat.com> <1256233193.3687.40.camel@tonnant> <20091023082000.572614f1@infradead.org> Message-ID: <1256313079.7986.20.camel@tonnant> On Fri, 2009-10-23 at 08:20 -0700, Arjan van de Ven wrote: > On Thu, 22 Oct 2009 18:39:53 +0100 > Jon Masters wrote: > > > Don't forget to mention the more paranoid hand-waving about removing > > RAM chips at runtime with liquid nitrogen after going into suspend and > > hax0ring. I think there will be more upstream discussion anyway. > > I'm sorry but this argument makes no sense whatsoever. Smiley face missed off there - I wasn't being serious about the attacking of TXT. At the end of the day, if you've got physical access to a system, there are worse things you can do. Jon. From snecklifter at gmail.com Fri Oct 23 17:34:33 2009 From: snecklifter at gmail.com (Christopher Brown) Date: Fri, 23 Oct 2009 18:34:33 +0100 Subject: CONFIG_INTEL_TXT In-Reply-To: <20091023082000.572614f1@infradead.org> References: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> <1256232255.4443.141.camel@dhcp231-106.rdu.redhat.com> <1256233193.3687.40.camel@tonnant> <20091023082000.572614f1@infradead.org> Message-ID: <364d303b0910231034g10b8b028o2702e68cc3f1192f@mail.gmail.com> 2009/10/23 Arjan van de Ven : > On Thu, 22 Oct 2009 18:39:53 +0100 > Jon Masters wrote: > >> Don't forget to mention the more paranoid hand-waving about removing >> RAM chips at runtime with liquid nitrogen after going into suspend and >> hax0ring. I think there will be more upstream discussion anyway. > > I'm sorry but this argument makes no sense whatsoever. > > Claiming that a feature should not be enabled because someone is talking > about a mythical attack that is waaay outside the scope of what a > technology wants to protect is not solid reasoning, it's fear mongering > instead. All the same, it was disappointing news to me to read that Intel are even pushing stuff that leverages binary blobs with no source code. There would be nothing to fear and no need for fear mongering if it was an open blob. It would make the whole argument moot. -- Christopher Brown From eparis at redhat.com Fri Oct 23 17:51:36 2009 From: eparis at redhat.com (Eric Paris) Date: Fri, 23 Oct 2009 13:51:36 -0400 Subject: CONFIG_INTEL_TXT In-Reply-To: <364d303b0910231034g10b8b028o2702e68cc3f1192f@mail.gmail.com> References: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> <1256232255.4443.141.camel@dhcp231-106.rdu.redhat.com> <1256233193.3687.40.camel@tonnant> <20091023082000.572614f1@infradead.org> <364d303b0910231034g10b8b028o2702e68cc3f1192f@mail.gmail.com> Message-ID: <1256320296.4443.177.camel@dhcp231-106.rdu.redhat.com> On Fri, 2009-10-23 at 18:34 +0100, Christopher Brown wrote: > 2009/10/23 Arjan van de Ven : > > On Thu, 22 Oct 2009 18:39:53 +0100 > > Jon Masters wrote: > > > >> Don't forget to mention the more paranoid hand-waving about removing > >> RAM chips at runtime with liquid nitrogen after going into suspend and > >> hax0ring. I think there will be more upstream discussion anyway. > > > > I'm sorry but this argument makes no sense whatsoever. > > > > Claiming that a feature should not be enabled because someone is talking > > about a mythical attack that is waaay outside the scope of what a > > technology wants to protect is not solid reasoning, it's fear mongering > > instead. > > All the same, it was disappointing news to me to read that Intel are > even pushing stuff that leverages binary blobs with no source code. > There would be nothing to fear and no need for fear mongering if it > was an open blob. It would make the whole argument moot. No, Arjan is right. Jon is talking about wildly unrelated system attack vectors which are in no way related to TXT or to the binary blob. Jon was out of line seemingly trying to scare people away from this technology for wholly illogical reasons. It's like we're talking about putting a lock on the window and Jon's talking about cutting through the walls. It's just not useful. Open or closed blob is irrelevant and does not influence the situation to his fear mongering line of attack. Please, however, continue to be disappointed that Intel is pushing a closed source blob. That is a productive train of thought :) -Eric From jcm at redhat.com Fri Oct 23 19:46:13 2009 From: jcm at redhat.com (Jon Masters) Date: Fri, 23 Oct 2009 20:46:13 +0100 Subject: CONFIG_INTEL_TXT In-Reply-To: <1256320296.4443.177.camel@dhcp231-106.rdu.redhat.com> References: <1256225597.2191.57.camel@moss-pluto.epoch.ncsc.mil> <1256232255.4443.141.camel@dhcp231-106.rdu.redhat.com> <1256233193.3687.40.camel@tonnant> <20091023082000.572614f1@infradead.org> <364d303b0910231034g10b8b028o2702e68cc3f1192f@mail.gmail.com> <1256320296.4443.177.camel@dhcp231-106.rdu.redhat.com> Message-ID: <1256327174.7986.38.camel@tonnant> On Fri, 2009-10-23 at 13:51 -0400, Eric Paris wrote: > No, Arjan is right. Jon is talking about wildly unrelated system attack > vectors which are in no way related to TXT or to the binary blob. I made a joke about paranoid ranting on LKML and missed off a smiley face...sorry! :) :) :) There are bigger things to worry about than someone taking the RAM chips out of my system while it's suspended. Jon. From bugs at cherrybyte.me.uk Fri Oct 30 17:21:35 2009 From: bugs at cherrybyte.me.uk (planetf1) Date: Fri, 30 Oct 2009 17:21:35 +0000 Subject: Checking if running kernel compiled with CONFIG_PREEMPT Message-ID: I have a 2.6.31 kernel from F12. I believe I've built it with CONFIG_PREEMPT but given the intracacies of the rpm build, what's the easiest way to check an installed kernel to see if that flag had been used during build? Thanks Nigel.