Re: [PATCH] Clustering indirect blocks in Ext3
On Thu, Nov 15, 2007 at 11:02:19PM -0800, Andrew Morton wrote: > On Thu, 15 Nov 2007 21:02:46 -0800 "Abhishek Rai" <[EMAIL PROTECTED]> wrote: ... > > 3. e2fsck speedup with metaclustering varies from disk > > to disk with most benefit coming from disks which have a large number > > of indirect blocks. For disks which have few indirect blocks, fsck > > usually doesn't take too long anyway and hence it's OK not to deliver > > a huge speedup there. But in all cases, metaclustering doesn't cause > > any degradation in IO performance as seen in the benchmarks above. > > Less speedup, for more-and-smaller files, it appears. > > An important question is: how does it stand up over time? Simply laying > files out a single time on a fresh fs is the easy case. But what happens > if that disk has been in continuous create/delete/truncate/append usage for > six months? Try Chris Mason's compilebench, which is a decent aging simulation. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] PCI: Add PCI quirk function for some chipsets
Subject: PCI: Add PCI quirk function for some chipsets From: Zhao Yakui <[EMAIL PROTECTED]> PCI quirk function is added for some chipsets so that the resources behind LPC bridge can be reserved. Signed-off-by: Li Shaohua <[EMAIL PROTECTED]> Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]> --- drivers/pci/quirks.c|6 ++ include/linux/pci_ids.h |2 ++ 2 files changed, 8 insertions(+) Index: linux-2.6.24-rc2/drivers/pci/quirks.c === --- linux-2.6.24-rc2.orig/drivers/pci/quirks.c +++ linux-2.6.24-rc2/drivers/pci/quirks.c @@ -465,6 +465,12 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_I DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_0, quirk_ich6_lpc_acpi ); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_2, quirk_ich6_lpc_acpi ); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_3, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_1, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH8_4, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_2, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_4, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_7, quirk_ich6_lpc_acpi ); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_ICH9_8, quirk_ich6_lpc_acpi ); /* * VIA ACPI: One IO region pointed to by longword at Index: linux-2.6.24-rc2/include/linux/pci_ids.h === --- linux-2.6.24-rc2.orig/include/linux/pci_ids.h +++ linux-2.6.24-rc2/include/linux/pci_ids.h @@ -2314,6 +2314,8 @@ #define PCI_DEVICE_ID_INTEL_ICH9_4 0x2914 #define PCI_DEVICE_ID_INTEL_ICH9_5 0x2919 #define PCI_DEVICE_ID_INTEL_ICH9_6 0x2930 +#define PCI_DEVICE_ID_INTEL_ICH9_7 0x2916 +#define PCI_DEVICE_ID_INTEL_ICH9_8 0x2918 #define PCI_DEVICE_ID_INTEL_82855PM_HB 0x3340 #define PCI_DEVICE_ID_INTEL_82830_HB 0x3575 #define PCI_DEVICE_ID_INTEL_82830_CGC 0x3577 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH]: PNP: Increase the value of PNP constant
Subject: PNP: Increase the value of PNP constant
From: Zhao Yakui <[EMAIL PROTECTED]>
On some systems the number of resources(IO,MEM) returnedy by PNP
device is greater than the PNP constant, for example motherboard devices.
It brings that some resources can't be reserved and resource confilicts.
This will cause PCI resources are assigned wrongly in some systems, and
cause hang. This is a regression since we deleted ACPI motherboard
driver and use PNP system driver.
Andrew, I thought this is an urgent issue and should be fixed ASAP, and
this is a good candidate for -stable tree
Signed-off-by: Li Shaohua <[EMAIL PROTECTED]>
Signed-off-by: Zhao Yakui <[EMAIL PROTECTED]>
---
drivers/pnp/pnpacpi/rsparser.c | 18 --
include/linux/pnp.h|4 ++--
2 files changed, 18 insertions(+), 4 deletions(-)
Index: linux-2.6.24-rc2/include/linux/pnp.h
===
--- linux-2.6.24-rc2.orig/include/linux/pnp.h
+++ linux-2.6.24-rc2/include/linux/pnp.h
@@ -13,8 +13,8 @@
#include
#include
-#define PNP_MAX_PORT 8
-#define PNP_MAX_MEM4
+#define PNP_MAX_PORT 24
+#define PNP_MAX_MEM12
#define PNP_MAX_IRQ2
#define PNP_MAX_DMA2
#define PNP_NAME_LEN 50
Index: linux-2.6.24-rc2/drivers/pnp/pnpacpi/rsparser.c
===
--- linux-2.6.24-rc2.orig/drivers/pnp/pnpacpi/rsparser.c
+++ linux-2.6.24-rc2/drivers/pnp/pnpacpi/rsparser.c
@@ -82,9 +82,11 @@ static void pnpacpi_parse_allocated_irqr
while (!(res->irq_resource[i].flags & IORESOURCE_UNSET) &&
i < PNP_MAX_IRQ)
i++;
- if (i >= PNP_MAX_IRQ)
+ if (i >= PNP_MAX_IRQ) {
+ printk(KERN_ERR "Exceed the max number of IRQ resource: "
+ "%d \n",PNP_MAX_IRQ);
return;
-
+ }
#ifdef CONFIG_X86
if (gsi < 16 && (triggering != ACPI_EDGE_SENSITIVE ||
polarity != ACPI_ACTIVE_HIGH)) {
@@ -173,6 +175,10 @@ static void pnpacpi_parse_allocated_dmar
}
res->dma_resource[i].start = dma;
res->dma_resource[i].end = dma;
+ } else {
+ printk(KERN_ERR "Exceed the max number of DMA resource: "
+ "%d \n",PNP_MAX_DMA);
+ return;
}
}
@@ -194,6 +200,10 @@ static void pnpacpi_parse_allocated_iore
}
res->port_resource[i].start = io;
res->port_resource[i].end = io + len - 1;
+ } else {
+ printk(KERN_ERR "Exceed the max number of IO Resource: "
+ "%d \n",PNP_MAX_PORT);
+ return;
}
}
@@ -217,6 +227,10 @@ static void pnpacpi_parse_allocated_memr
res->mem_resource[i].start = mem;
res->mem_resource[i].end = mem + len - 1;
+ } else {
+ printk(KERN_ERR "Exceed the max number of Mem Resource: "
+ "%d \n",PNP_MAX_MEM);
+ return;
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Fix UML broken (was Re: User Mode Linux still broken in 2.6.23.1)
On Thu, Nov 15, 2007 at 11:01:43PM -0600, Rob Landley wrote: > On Thursday 15 November 2007 21:08:32 WANG Cong wrote: > > On Thu, Nov 15, 2007 at 01:06:08PM -0800, Greg KH wrote: > > >Hm, not good. I'll let Jeff handle this :) > > > > Could you please try this patch? Can it fix the error? > > > > Signed-off-by: WANG Cong <[EMAIL PROTECTED]> > > Oh what a good idea. > > Signed-off-by: Rob Landley <[EMAIL PROTECTED]> Heh, we came full circle here, this was Rob's original patch :) Rob, I'll queue this up for the next cycle, now that you've verified that it was not fixed already, thanks for testing. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86: disable preemption in delay_tsc()
On Fri, 16 Nov 2007 08:17:08 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > It sounds like it would work OK. What is the setup cost for a usleep?
> > I'd have thought that code which does something like
> >
> > while (i++ < 1000) {
> > foo();
> > udelay(1);
> > }
> >
> > would take qiute a bit longer with such a change?
>
> full roundtrip cost ought to be below 10 usecs, depending on the system.
Ow. So the above timeout would take 10x longer. That probably won't break
anything, but quite a few drivers do udelay(1) for post-IO settling times
and they might not like it.
> There's no problem doing a non-preemptible udelay up to 10 usecs and we
> could use usleep above that.
Yup, with a few smarts in there we could work out which is the best to use,
and also compensate for the setup costs.
It doesn't sound very 2.6.24ish though.
As a quicky things perhaps we could only do the
preempt_disable()/preempt_enable()
if the TSCs are unsynced? Do we reliably know that? I guess not..
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86: disable preemption in delay_tsc()
On Fri, 16 Nov 2007 07:13:32 +0100 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> > > > x86: disable preemption in delay_tsc()
> > > >
> > > > Marin Mitov points out that delay_tsc() can misbehave if it is
> > > > preempted and rescheduled on a different CPU which has a skewed
> > > > TSC. Fix it by disabling preemption.
> > > >
> > >
> > > this worries me.. this appears to effectively disable preemption
> > > during udelay() and mdelay() loops... which are very obvious latency
> > > inducers.
> > >
> > > Now you can argue that if you're preemptible you should have used
> > > msleep() and co, and I'll totally buy that.
> > >
> > >
> > > Maybe we should just check if we're still on the same cpu or
> > > something, or have a cheap way to pin a process to a cpu but
> > > both are longer term solutions.
> >
> > Yes, we can do better.
> >
> > But this bug can cause very rare failures in probably a large number
> > of device drivers on a minorty of machines. Ugly. So I felt it best
> > to plug it fast while people think about more sophisticated fixes.
>
> how about using usleep() transparently if high-res timers are active and
> we have !preempt_count()?
And CONFIG_PREEMPT, of course
> That would be a sufficient solution and would
> avoid all the calibration and per-cpu-ness problems.
It sounds like it would work OK. What is the setup cost for a usleep? I'd
have thought that code which does something like
while (i++ < 1000) {
foo();
udelay(1);
}
would take qiute a bit longer with such a change?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clustering indirect blocks in Ext3
On Thu, 15 Nov 2007 21:02:46 -0800 "Abhishek Rai" <[EMAIL PROTECTED]> wrote: > (This patch was previously posted on linux-ext4 where Andreas Dilger > offered some valuable comments on it). > > This patch modifies the block allocation strategy in ext3 in order to > improve fsck performance. This was initially sent out as a patch for > ext2, but given the lack of ongoing development on ext2, I have > crossported it to ext3 instead. Slow fsck is not a serious problem on > ext3 due to journaling, but once in a while users do need to run full > fsck on their ext3 file systems. This can be due to several reasons: > (1) bad disk, bad crash, etc, (2) bug in jbd/ext3, and (3) every few > reboots, it's good to run fsck anyway. This patch will help reduce > full fsck time for ext3. I've seen 50-65% reduction in fsck time when > using this patch on a near-full file system. With some fsck > optimizations, this figure becomes 80%. > > Most of Ext3 metadata is clustered on disk. For example, Ext3 > partitions the block space into block groups and stores the metadata > for each block group (inode table, block bitmap, inode bitmap) at the > beginning of the block group. Clustering related metadata together not > only helps ext3 I/O performance by keeping data and related metadata > close together, but also helps fsck since it is able to find all the > metadata in one place. However, indirect blocks are an exception. > Indirect blocks are allocated on-demand and are spread out along with > the data. This layout enables good I/O performance due to the close > proximity between an indirect block and its data blocks but it makes > things difficult for fsck which must now rotate almost the entire disk > in order to read all indirect blocks. In fact, our measurements have > indicated that for most ext3 disks on which fsck takes a long time, > >80% of the time is spent reading indirect blocks. So speeding up > indirect block read accesses in fsck can significantly improve fsck > times. > > One solution to this problem implemented in this patch is to cluster > indirect blocks together on a per group basis, similar to how inodes > and bitmaps are clustered. So we have a section of blocks around the middle of the blockgroup which are used for indirect blocks. Presmably it starts around 50% of the way into the blockgroup? How do you decide its size? What happens when it fills up but we still have room for more data blocks in that blockgroup? Can this reserved area cause disk space wastage (all data blocks used, metacluster area not yet full). The file data block allocator now needs to avoid allocating blocks from inside this reserved area. How is this implemented? It is awfully similar to the existing reservations code - does it utilise that code? > Indirect block clusters (metaclusters) help > fsck performance by enabling fsck to fetch all indirect blocks by > reading from a few locations on the disk instead of rotating through > the entire disk. Unfortunately, a naive clustering scheme for indirect > blocks can hurt I/O performance, as it separates out indirect blocks > and corresponding direct blocks on the disk. So an I/O to a direct > block whose indirect block is not in the page cache now needs to incur > a longer seek+rotational delay in moving the disk head from the > indirect block to the direct block. > > So our goal then is to implement metaclustering without having any > impact (<0.1%) on I/O performance. Fortunately, current ext3 I/O > algorithm is not the most efficient, improving it can camouflage the > performance hit we suffer due to metaclustering. In fact, > metaclustering automatically enables one such optimization. When doing > sequential read from a file and reading an indirect block for it, we > readahead several indirect blocks of the file from the same > metacluster. Moreover, when possible we do this asynchronously. This > reduces the seek+rotational latency associated with seeking between > data and indirect blocks during a (long) sequential read. > > There is one more design choice that affect the performance of this > patch: location and number of metaclusters per block group. Currently > we have one metacluster per block group and it is located at the > center of the block group. We adopted this scheme after evaluating > three possible locations of metaclusters: beginning, middle, and end > of block group. We did not evaluate configurations with >1 metacluster > per block group. In our experiments, the middle configuration did not > cause any performance degradation for sequential and random reads. > Whereas putting the metacluster at the beginning of the block group > yields best performance for sequential reads (write performance is > unaffected by this change), putting it in the middle helps random > reads. Since the "middle path" maintains status quo, we adopted that > in our change. > > Performance evaluation results: > Setup: > RAM: 8GB > Disk: 400GB disk. > CPU: Dual core
Re: [BUG] Strange 1-second pauses during Resume-from-RAM
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > Is there a version of these that works with 2.6.23.1 ?
>
> yes, i've backported it and have uploaded the v2.6.23 version to:
>
>
> http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.23.1-combo.patch
btw., if the trace is too large and the interesting section of suspend
does not fit into it then you can narrow it down to the most important
events only by changing this in trace-cmd.c:
system("echo 1 > /proc/sys/kernel/mcount_enabled");
to:
system("echo 0 > /proc/sys/kernel/mcount_enabled");
that way we'll still trace IRQs and scheduling events, which is enough
to see roughly where the delay is happening. To include symbolic
backtraces in the trace, do this:
echo 1 > /proc/sys/kernel/stackframe_tracing
to get such trace entries:
ls 3688 1D..3 4642us+: deactivate_task (0 0)
ls 3688 1D..3 4644us+:
schedule()<-do_exit()<-sys_exit_group()<-sys_exit_group()
ls 3688 1D..3 4647us+: sysenter_past_esp()<-( -1)()<-(0)()<-(
0)()
0 1D..2 4652us : schedule (0 20)
this way we can see why a task goes to sleep and which exact kernel
codepath is waking it up.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] intel-iommu fixes
On Sunday 28 October 2007 21:51, Al Viro wrote: > -#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings) > +#define MAX_FAULT_REASON_IDX ARRAY_SIZE(fault_reason_strings) - 1 The macro is unsafe without yet another ()s around it. -- vda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86: disable preemption in delay_tsc()
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> It sounds like it would work OK. What is the setup cost for a usleep?
> I'd have thought that code which does something like
>
> while (i++ < 1000) {
> foo();
> udelay(1);
> }
>
> would take qiute a bit longer with such a change?
full roundtrip cost ought to be below 10 usecs, depending on the system.
There's no problem doing a non-preemptible udelay up to 10 usecs and we
could use usleep above that.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86: disable preemption in delay_tsc()
* Andrew Morton <[EMAIL PROTECTED]> wrote: > > > x86: disable preemption in delay_tsc() > > > > > > Marin Mitov points out that delay_tsc() can misbehave if it is > > > preempted and rescheduled on a different CPU which has a skewed > > > TSC. Fix it by disabling preemption. > > > > > > > this worries me.. this appears to effectively disable preemption > > during udelay() and mdelay() loops... which are very obvious latency > > inducers. > > > > Now you can argue that if you're preemptible you should have used > > msleep() and co, and I'll totally buy that. > > > > > > Maybe we should just check if we're still on the same cpu or > > something, or have a cheap way to pin a process to a cpu but > > both are longer term solutions. > > Yes, we can do better. > > But this bug can cause very rare failures in probably a large number > of device drivers on a minorty of machines. Ugly. So I felt it best > to plug it fast while people think about more sophisticated fixes. how about using usleep() transparently if high-res timers are active and we have !preempt_count()? That would be a sufficient solution and would avoid all the calibration and per-cpu-ness problems. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-rt1
* Steven Rostedt <[EMAIL PROTECTED]> wrote: > Ingo, > > Do we still need to have the realtime-lsm.patch? It has been > considered obsolete for over a year now. Can we finally remove it. yeah, we can drop it. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: High priority tasks break SMP balancer?
* Micah Dowty <[EMAIL PROTECTED]> wrote: > > I am a bit at a loss as to how this could relate to the patch. This > > looks like a load balance logic issue that causes the load > > calculation to go wrong? > > My best guess is that this has something to do with the timing with > which we sample the CPU's instantaneous load when calculating the load > averages.. but I still understand only the basics of the scheduler and > SMP balancer. All I really know for sure at this point regarding your > patch is that git-bisect found it for me. hm, your code uses timeouts for this, right? The CPU load average that is used for SMP load balancing is sampled from the scheduler tick - and has been sampled from the scheduler tick for eons. v2.6.23 defaulted to a different method but v2.6.24 samples it from the tick again. So my guess is, your testcode behave similarly on 2.6.22 too, correct? Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] keyspan: init termios properly
On Thu, Nov 15, 2007 at 01:10:16PM -0800, Lucy McCoy wrote: Hi Lucy, > I'm not familiar with the termios stuff on Linux so can you take a look > at the following modified code to see if this solves your NULL ptr problem? will test the patch tomorrow and get back to you with results. > Does cflag need to be set to anything other than CS8? i'm not that familiar with serial port settings either, but IIRC the cflag is used to set the requested byte size of the transferred chars (cf http://en.wikipedia.org/wiki/Serial_port#Data_Bits). Thus, according to the above CS8 is used for setting up transfer of any kind of data over the serial connection. > Is keyspan_open_port() always followed by a keyspan_set_termios()? err, you mean keyspan_open() ... ..and yes, almost all of the usb to serial converter drivers call their own *_set_termios-routine so that they could "synchronize" the line discipline user settings with those of the converter. -- Regards/Gruß, Boris. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NET]: rt_check_expire() can take a long time, add a cond_resched()
On Fri, 16 Nov 2007 05:12:21 +0100
Eric Dumazet <[EMAIL PROTECTED]> wrote:
> Eric Dumazet a écrit :
> > Arjan van de Ven a écrit :
> >> On Thu, 15 Nov 2007 04:01:48 GMT
> >> Linux Kernel Mailing List wrote:
> >>
> >>> Gitweb:
> >>> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d90bf5a976793edfa88d3bb2393f0231eb8ce1e5
> >>>
> >>>
> >>> Commit: d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 Parent:
> >>> 66ba886254edbbd9442d30f1eef6f6fb0145027d Author: Eric Dumazet
> >>> <[EMAIL PROTECTED]> AuthorDate: Wed Nov 14 16:14:05 2007 -0800
> >>> Committer: David S. Miller <[EMAIL PROTECTED]>
> >>> CommitDate: Wed Nov 14 16:14:05 2007 -0800
> >>>
> >>> [NET]: rt_check_expire() can take a long time, add a
> >>> cond_resched() On commit
> >>> 39c90ece7565f5c47110c2fa77409d7a9478bd5b:
> >>
> >>> When the IP route cache is big, rt_check_expire() can take a
> >>> long time to run. (default settings : 20% of the hash table is
> >>> scanned at each invocation)
> >>> Adding cond_resched() helps giving cpu to higher priority
> >>> tasks if
> >>> necessary.
> >>> Using a "if (need_resched())" test before calling
> >>> "cond_resched();" is necessary to avoid spending too much time
> >>> doing the resched check.
> >>
> >> int __sched cond_resched(void)
> >> {
> >> if (need_resched() && .
> >>
> >> somehow I wonder why the second if() is useful at all; it's another
> >> spot for a branch predictor to miss... and a void function call is
> >> really really cheap...
> >
> > Its not that cheap. The ChangeLog included my own numbers, on a
> > Pentium M machine. (i686, 1.6 GHz, 1.5 GB ram)
> >
> > Without "if (need_resched())" (so calling need_resched() X.XXX.XXX
> > times), each run takes 88ms
> >
> > With the extra check (and *much* less function calls), each run
> > takes 25ms
> >
>
> Looking at cond_resched(), I think the extra cost comes from
> "mov %esp,%edx ; and $0xe000,%edx" (current_thread_info())
>
> I dont have oprofile numbers yet, but I suspect CPU may have some
> delays to compute this pointer value, since %esp is probably 'busy'
> because of the preceding "call"
yeah the explicit reference makes the stack pointer tracking engine do a
commit I suspect which then also creates a data dependency in the code
flow.
however... this is likely a good argument for making cond_resched() as a
whole a #define (or inline) that does this test and then calls the out
of line code (which then doesn't need to retest, so it avoids the
double test)...
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] Strange 1-second pauses during Resume-from-RAM
* Mark Lord <[EMAIL PROTECTED]> wrote: >> sorry, wrong URLs, the correct links are: >> >> >> http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.24-rc2-git5-combo.patch >>http://redhat.com/~mingo/latency-tracing-patches/trace-cmd.c > .. > > Is there a version of these that works with 2.6.23.1 ? yes, i've backported it and have uploaded the v2.6.23 version to: http://redhat.com/~mingo/latency-tracing-patches/latency-tracer-v2.6.23.1-combo.patch Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi Roman.
> > If user did NOT specify ARCH we should use the kernel configuration - which
> > your solution fail to do.
>
> To make this easy I attached the patch which reverts the problematic
> changes and then you only need this simple change to force the 64BIT value
> for ARCH={i386,x86_64}, otherwise it's set by the user:
Just eyeballing your patch I made following observations:
1) make all*config, randconfig, defconfig is broken on 64-bit boxes
2) A pure code refactoring patch is reverted for no obvious reason
3) Behavioral changes are not documented:
- 32-bit/64-bit can only be selected in config is you specify ARCH=x86
- ARCH= takes precedence over kernel config for a configured kernel
4) The changelogs miss title on reverted patches
All points are trivial to fix so I do not say your approach is
bad - just that the supplied patch is not good enough.
I will fix it up tonight and test it.
Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
On Nov 15, 2007 10:34 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Thu, 15 Nov 2007 22:24:12 +0100 > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > > > The problem with the first bisect-try was, that everything between > > bisect-good: r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename > > and > > bisect-bad: use-struct-path-in-struct-svc_export > > did not compile like this: > > > > CC [M] fs/nfsd/vfs.o > > fs/nfsd/vfs.c: In function 'nfsd_rename': > > fs/nfsd/vfs.c:1695: error: request for member 'mnt' in something not a > > structure or union > > argh. I'd incorrectly worked out that > nfsd-fix-wrong-mnt_writer-count-in-rename.patch was a fix against > r-o-bind-mounts-elevate-write-count-over-calls-to-vfs_rename.patch however > it is in fact a fix against use-struct-path-in-struct-svc_export.patch. > > My life sucks. > I think the placement was correct, but the patch itself was made against a tree that already contained the changes from use-struct-path-in-struct-svc_export.patch. nfsd-fix-wrong-mnt_writer-count-in-rename.patch should have used the old naming ex_mnt and only use-struct-path-in-struct-svc_export.patch should have changed it to ex_path.mnt. Torsten - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.24-rc2-mm1] memory hotplug x86_64 fix [3/3] fix section mismatch in init_memory_mapping
On Thu, 15 Nov 2007 16:59:35 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Index: linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c
> > ===
> > --- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/init_64.c
> > +++ linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c
> > @@ -347,7 +347,7 @@ static void __init find_early_table_spac
> > /* Setup the direct mapping of the physical memory at PAGE_OFFSET.
> > This runs before bootmem is initialized and gets pages directly from
> > the
> > physical memory. To access them they are temporarily mapped. */
> > -void __meminit init_memory_mapping(unsigned long start, unsigned long end)
> > +void __init_refok init_memory_mapping(unsigned long start, unsigned long
> > end)
> > {
> > unsigned long next;
> >
>
> again, I _think_ this fixes a bug in mainline. Can you check that please?
>
Yes, this section mismatch happens on 2.6.24-rc2.
Thanks,
-Kame
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch] Fix UML broken (was Re: User Mode Linux still broken in 2.6.23.1)
On Thursday 15 November 2007 21:08:32 WANG Cong wrote: > On Thu, Nov 15, 2007 at 01:06:08PM -0800, Greg KH wrote: > >Hm, not good. I'll let Jeff handle this :) > > Could you please try this patch? Can it fix the error? > > Signed-off-by: WANG Cong <[EMAIL PROTECTED]> Oh what a good idea. Signed-off-by: Rob Landley <[EMAIL PROTECTED]> Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Clustering indirect blocks in Ext3
(This patch was previously posted on linux-ext4 where Andreas Dilger offered some valuable comments on it). This patch modifies the block allocation strategy in ext3 in order to improve fsck performance. This was initially sent out as a patch for ext2, but given the lack of ongoing development on ext2, I have crossported it to ext3 instead. Slow fsck is not a serious problem on ext3 due to journaling, but once in a while users do need to run full fsck on their ext3 file systems. This can be due to several reasons: (1) bad disk, bad crash, etc, (2) bug in jbd/ext3, and (3) every few reboots, it's good to run fsck anyway. This patch will help reduce full fsck time for ext3. I've seen 50-65% reduction in fsck time when using this patch on a near-full file system. With some fsck optimizations, this figure becomes 80%. Most of Ext3 metadata is clustered on disk. For example, Ext3 partitions the block space into block groups and stores the metadata for each block group (inode table, block bitmap, inode bitmap) at the beginning of the block group. Clustering related metadata together not only helps ext3 I/O performance by keeping data and related metadata close together, but also helps fsck since it is able to find all the metadata in one place. However, indirect blocks are an exception. Indirect blocks are allocated on-demand and are spread out along with the data. This layout enables good I/O performance due to the close proximity between an indirect block and its data blocks but it makes things difficult for fsck which must now rotate almost the entire disk in order to read all indirect blocks. In fact, our measurements have indicated that for most ext3 disks on which fsck takes a long time, >80% of the time is spent reading indirect blocks. So speeding up indirect block read accesses in fsck can significantly improve fsck times. One solution to this problem implemented in this patch is to cluster indirect blocks together on a per group basis, similar to how inodes and bitmaps are clustered. Indirect block clusters (metaclusters) help fsck performance by enabling fsck to fetch all indirect blocks by reading from a few locations on the disk instead of rotating through the entire disk. Unfortunately, a naive clustering scheme for indirect blocks can hurt I/O performance, as it separates out indirect blocks and corresponding direct blocks on the disk. So an I/O to a direct block whose indirect block is not in the page cache now needs to incur a longer seek+rotational delay in moving the disk head from the indirect block to the direct block. So our goal then is to implement metaclustering without having any impact (<0.1%) on I/O performance. Fortunately, current ext3 I/O algorithm is not the most efficient, improving it can camouflage the performance hit we suffer due to metaclustering. In fact, metaclustering automatically enables one such optimization. When doing sequential read from a file and reading an indirect block for it, we readahead several indirect blocks of the file from the same metacluster. Moreover, when possible we do this asynchronously. This reduces the seek+rotational latency associated with seeking between data and indirect blocks during a (long) sequential read. There is one more design choice that affect the performance of this patch: location and number of metaclusters per block group. Currently we have one metacluster per block group and it is located at the center of the block group. We adopted this scheme after evaluating three possible locations of metaclusters: beginning, middle, and end of block group. We did not evaluate configurations with >1 metacluster per block group. In our experiments, the middle configuration did not cause any performance degradation for sequential and random reads. Whereas putting the metacluster at the beginning of the block group yields best performance for sequential reads (write performance is unaffected by this change), putting it in the middle helps random reads. Since the "middle path" maintains status quo, we adopted that in our change. Performance evaluation results: Setup: RAM: 8GB Disk: 400GB disk. CPU: Dual core hyperthreaded All measurements were taken 10 times or more until standard deviation was <2%. Machine was rebooted between runs and file system freshly formatted, also we made sure that there was nothing running on the machine at the time of the test. Notation: - 'vanilla': regular ext3 without any changes - 'mc': metaclustering ext3 Benchmark 1: Sequential write to a 10GB file followed by 'sync' 1. vanilla: Total: 3m9.0s User: 0.08 System: 23s-48s (very high variance) 2. mc: Total: 3m6.1s User: 0.08s System: 48.1s Benchmark 2: Sequential read from a 10GB file. Description: the file is created using same type of ext2 (mc or vanilla) 1. vanilla: Total: 3m14.5s User: 0.04s System: 13.4s 2. mc: Total: 3m14.5s User: 0.04s System: 13.3s Benchmark 3: Random read from a 300GB file Description: read using 512 byte
Re: [PATCH][2.6.24-rc2-mm1] memory hotplug x86_64 fix [2/3] fix section mismatch in vmammap_allock_block
On Thu, 15 Nov 2007 16:53:30 -0800 Andrew Morton <[EMAIL PROTECTED]> wrote: > > - return __alloc_bootmem_node(NODE_DATA(node), size, size, > > + return __earlyonly_bootmem_alloc(node, size, size, > > __pa(MAX_DMA_ADDRESS)); > > } > > > > AFACIT this is applicable to mainline? > > yes. I think so. Thanks, -Kame - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-rt1
On Nov 15, 2007 7:39 PM, Steven Rostedt <[EMAIL PROTECTED]> wrote: > > On Thu, 15 Nov 2007, Mark Knecht wrote: > > > > On Nov 15, 2007 10:40 AM, Steven Rostedt <[EMAIL PROTECTED]> wrote: > > > Finally! > > > > > > We are pleased to announce 2.6.24-rc2-rt1. > > > > > > > > > Hi Steve, > >Not sure I've ever posted on this list. Always looking to help out > > at my low level. > > > >Anyway, I tried building the kernel. My 1st two attempts, done > > running make menuconfig from scratch, didn't boot. I gave up on that > > for now and tried using make oldconfig from my 2.6.23-rt1 kernel (I'm > > so far behind!!) and ended up with this error. Not sure it's enough > > for you to find the bug. If you want/need more or want the config file > > let me know. > > > >I'm sure this is just me setting inappropriate bits but I figured I > > might as well send along the info. >/dev/null if it's inappropriate > > but let me know how to move forward if possible. > > > >As always thanks the the rt-kernel team for all you do. > > > > Cheers, > > Mark > > > > CC ipc/mqueue.o > > CC ipc/compat_mq.o > > LD ipc/built-in.o > > CC security/security.o > > CC security/dummy.o > > CC security/inode.o > > LD security/built-in.o > > CC [M] security/commoncap.o > > CC [M] security/realcap.o > > security/realcap.c: In function 'realtime_exit': > > security/realcap.c:129: error: implicit declaration of function > > 'mod_unreg_security' > > security/realcap.c:133: error: implicit declaration of function > > 'unregister_security' > > make[1]: *** [security/realcap.o] Error 1 > > make: *** [security] Error 2 > > lightning linux # > > Hi Mark, > > I guess you enabled the realtime capabilities (Realtime-LSM - Obsolete -) > > You could disable that, and try again. I'm not sending a fix (yet) > because ... > > > Ingo, > > Do we still need to have the realtime-lsm.patch? It has been considered > obsolete for over a year now. Can we finally remove it. > > -- Steve > Steve, I'd forgotten about that package going away. I think I've been building the interface forever in the kernel but then not actually using it. I haven't loaded the realtime_lsm driver in a long time. Certainly back in the 2.6.22 past somewhere since I stopped. Anyway, with that change to the config the rest of my old .config file seems to have worked. The kernel boots. I have Jack running realtime. No xruns in the few minutes I have left with this task tonight. [EMAIL PROTECTED] ~ $ uname -a Linux lightning 2.6.24-rc2-rt1 #4 PREEMPT RT Thu Nov 15 20:33:15 PST 2007 x86_64 AMD Athlon(tm) 64 Processor 3000+ AuthenticAMD GNU/Linux [EMAIL PROTECTED] ~ $ Very good so far. I'll continue to run the kernel over the next few days and see how things go. Nothing I do these days is a heavy load. Just desktop work with a little bit of audio but I still run the realtime kernel. Great work! Cheers, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NET]: rt_check_expire() can take a long time, add a cond_resched()
Eric Dumazet a écrit :
Arjan van de Ven a écrit :
On Thu, 15 Nov 2007 04:01:48 GMT
Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d90bf5a976793edfa88d3bb2393f0231eb8ce1e5
Commit: d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 Parent:
66ba886254edbbd9442d30f1eef6f6fb0145027d Author: Eric Dumazet
<[EMAIL PROTECTED]> AuthorDate: Wed Nov 14 16:14:05 2007 -0800
Committer: David S. Miller <[EMAIL PROTECTED]>
CommitDate: Wed Nov 14 16:14:05 2007 -0800
[NET]: rt_check_expire() can take a long time, add a
cond_resched() On commit 39c90ece7565f5c47110c2fa77409d7a9478bd5b:
When the IP route cache is big, rt_check_expire() can take a long
time to run. (default settings : 20% of the hash table is scanned at
each invocation)
Adding cond_resched() helps giving cpu to higher priority
tasks if
necessary.
Using a "if (need_resched())" test before calling
"cond_resched();" is necessary to avoid spending too much time doing
the resched check.
int __sched cond_resched(void)
{
if (need_resched() && .
somehow I wonder why the second if() is useful at all; it's another
spot for a branch predictor to miss... and a void function call is
really really cheap...
Its not that cheap. The ChangeLog included my own numbers, on a Pentium
M machine. (i686, 1.6 GHz, 1.5 GB ram)
Without "if (need_resched())" (so calling need_resched() X.XXX.XXX
times), each run takes 88ms
With the extra check (and *much* less function calls), each run takes 25ms
Looking at cond_resched(), I think the extra cost comes from
"mov %esp,%edx ; and $0xe000,%edx" (current_thread_info())
I dont have oprofile numbers yet, but I suspect CPU may have some delays
to compute this pointer value, since %esp is probably 'busy' because
of the preceding "call"
(In the case the "if (need_resched())" is done in rt_check_expire(),
compiler moves this pointer computation (current_thread_info()) out of the loop)
c055f926 :
c055f926: 89 e2 mov%esp,%edx
c055f928: 81 e2 00 e0 ff ff and$0xe000,%edx
c055f92e: 8b 42 08mov0x8(%edx),%eax
c055f931: a8 04 test $0x4,%al
c055f933: 74 1a je c055f94f
c055f935: f6 42 17 10 testb $0x10,0x17(%edx)
c055f939: 75 14 jnec055f94f
c055f93b: 83 3d 00 80 7c c0 01cmpl $0x1,0xc07c8000
c055f942: 75 0b jnec055f94f
c055f944: e8 2b 80 bb ff call c0117974 <__cond_resched>
c055f949: b8 01 00 00 00 mov$0x1,%eax
c055f94e: c3 ret
c055f94f: 31 c0 xor%eax,%eax
c055f951: c3 ret
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NET]: rt_check_expire() can take a long time, add a cond_resched()
From: Arjan van de Ven <[EMAIL PROTECTED]>
Date: Thu, 15 Nov 2007 19:38:02 -0800
> On Thu, 15 Nov 2007 04:01:48 GMT
> Linux Kernel Mailing List wrote:
>
> > Using a "if (need_resched())" test before calling
> > "cond_resched();" is necessary to avoid spending too much time doing
> > the resched check.
>
> int __sched cond_resched(void)
> {
> if (need_resched() && .
>
> somehow I wonder why the second if() is useful at all; it's another
> spot for a branch predictor to miss... and a void function call is
> really really cheap...
Not by Eric's tests. Please read the thread, he checked and it's
50ms more expensive to make the function call.
Please, when you notice something interesting in something flying
by on git-web, go check thing out we probably discussed the thing
you're interested in.
And please at least CC: netdev about networking patches, and also the
patch author, which I've corrected in this reply.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
x86_64: Make sparsemem/vmemmap the default memory model V2
Updated version against mainline. Looks even a bit cleaner.
x86_64: Make sparsemem/vmemmap the default memory model V2
V1->V2:
- Rediff against new upstream x86 code that unifies the Kconfig files.
Use sparsemem as the only memory model for UP, SMP and NUMA.
Measurements indicate that DISCONTIGMEM has a higher overhead
than sparsemem. And FLATMEMs benefits are minimal. So I think its
best to simply standardize on sparsemem.
Results of page allocator tests (test can be had via git from slab git
tree branch tests)
Measurements in cycle counts. 1000 allocations were performed and then the
average cycle count was calculated.
Order FlatMem Discontig SparseMem
0 639 665 641
1 567 647 593
2 679 774 692
3 763 967 781
4 9611501 962
5135623441392
6222439822336
7486972255074
8 12500 14048 12732
9 27926 28223 28165
10 58578 58714 58682
(Note that FlatMem is an SMP config and the rest NUMA configurations)
Memory use:
SMP Sparsemem
-
Kernel size:
textdata bss dec hex filename
3849268 397739 1264856 5511863 541ab7 vmlinux
total used free sharedbuffers cached
Mem: 8242252 411648201088 0352 11512
-/+ buffers/cache: 293008212952
Swap: 9775512 09775512
SMP Flatmem
---
Kernel size:
textdata bss dec hex filename
3844612 397739 1264536 5506887 540747 vmlinux
So 4.5k growth in text size vs. FLATMEM.
total used free sharedbuffers cached
Mem: 8244052 405448203508 0352 11484
-/+ buffers/cache: 287088215344
2k growth in overall memory use after boot.
NUMA discontig:
textdata bss dec hex filename
3888124 470659 1276504 5635287 55fcd7 vmlinux
total used free sharedbuffers cached
Mem: 8256256 569088199348 0352 11496
-/+ buffers/cache: 450608211196
Swap: 9775512 09775512
NUMA sparse:
textdata bss dec hex filename
3896428 470659 1276824 5643911 561e87 vmlinux
8k text growth. Given that we fully inline virt_to_page and friends now
that is rather good.
total used free sharedbuffers cached
Mem: 8264720 572408207480 0352 11516
-/+ buffers/cache: 453728219348
Swap: 9775512 09775512
The total available memory is increased by 8k.
This patch makes sparsemem the default and removes discontig and
flatmem support from x86.
Acked-by: Andi Kleen <[EMAIL PROTECTED]>
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
arch/x86/Kconfig | 20 +---
arch/x86/configs/x86_64_defconfig |9 -
arch/x86/kernel/machine_kexec_64.c |5 ---
arch/x86/mm/init_64.c | 30 ---
arch/x86/mm/ioremap_64.c | 17 ---
arch/x86/mm/numa_64.c | 21 -
arch/x86/mm/srat_64.c | 57 -
include/asm-x86/mmzone_64.h|6 ---
include/asm-x86/page_64.h |3 -
include/asm-x86/sparsemem_64.h |4 --
10 files changed, 8 insertions(+), 164 deletions(-)
Index: linux-2.6/arch/x86/configs/x86_64_defconfig
===
--- linux-2.6.orig/arch/x86/configs/x86_64_defconfig2007-11-13
11:52:34.785633363 -0800
+++ linux-2.6/arch/x86/configs/x86_64_defconfig 2007-11-15 19:39:59.073745644
-0800
@@ -145,15 +145,6 @@ CONFIG_K8_NUMA=y
CONFIG_NODES_SHIFT=6
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NUMA_EMU=y
-CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
-CONFIG_ARCH_DISCONTIGMEM_DEFAULT=y
-CONFIG_ARCH_SPARSEMEM_ENABLE=y
-CONFIG_SELECT_MEMORY_MODEL=y
-# CONFIG_FLATMEM_MANUAL is not set
-CONFIG_DISCONTIGMEM_MANUAL=y
-# CONFIG_SPARSEMEM_MANUAL is not set
-CONFIG_DISCONTIGMEM=y
-CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_NEED_MULTIPLE_NODES=y
# CONFIG_SPARSEMEM_STATIC is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
Index: linux-2.6/arch/x86/kernel/machine_kexec_64.c
===
--- linux-2.6.orig/arch/x86/kernel/machine_kexec_64.c 2007-11-13
11:52:34.793633597 -0800
+++ linux-2.6/arch/x86/kernel/machine_kexec_64.c2007-11-15
19:39:59.126128308 -0800
@@ -234,10 +234,5 @@ NORET_TYPE void machine_kexec(struct kim
void arch_crash_save_vmcoreinfo(void)
{
VMCOREINFO_SYMBOL(init_level4_pgt);
-
-#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
- VMCOREINFO_SYMBOL(node_data);
- VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
-#endif
}
Index:
Re: [NET]: rt_check_expire() can take a long time, add a cond_resched()
Arjan van de Ven a écrit :
On Thu, 15 Nov 2007 04:01:48 GMT
Linux Kernel Mailing List wrote:
Gitweb:
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d90bf5a976793edfa88d3bb2393f0231eb8ce1e5
Commit: d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 Parent:
66ba886254edbbd9442d30f1eef6f6fb0145027d Author: Eric Dumazet
<[EMAIL PROTECTED]> AuthorDate: Wed Nov 14 16:14:05 2007 -0800
Committer: David S. Miller <[EMAIL PROTECTED]>
CommitDate: Wed Nov 14 16:14:05 2007 -0800
[NET]: rt_check_expire() can take a long time, add a
cond_resched()
On commit 39c90ece7565f5c47110c2fa77409d7a9478bd5b:
When the IP route cache is big, rt_check_expire() can take a long
time to run. (default settings : 20% of the hash table is scanned at
each invocation)
Adding cond_resched() helps giving cpu to higher priority tasks if
necessary.
Using a "if (need_resched())" test before calling
"cond_resched();" is necessary to avoid spending too much time doing
the resched check.
int __sched cond_resched(void)
{
if (need_resched() && .
somehow I wonder why the second if() is useful at all; it's another
spot for a branch predictor to miss... and a void function call is
really really cheap...
Its not that cheap. The ChangeLog included my own numbers, on a Pentium M
machine. (i686, 1.6 GHz, 1.5 GB ram)
Without "if (need_resched())" (so calling need_resched() X.XXX.XXX times),
each run takes 88ms
With the extra check (and *much* less function calls), each run takes 25ms
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86: disable preemption in delay_tsc()
On Thu, 15 Nov 2007 19:41:16 -0800 Arjan van de Ven <[EMAIL PROTECTED]> wrote: > On Thu, 15 Nov 2007 04:00:47 GMT > Linux Kernel Mailing List wrote: > > > Gitweb: > > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=35d5d08a085c56f153458c3f5d8ce24123617faf > > Commit: 35d5d08a085c56f153458c3f5d8ce24123617faf Parent: > > 7eea436433b7b18045f272562e256976f593f7c0 Author: Andrew Morton > > <[EMAIL PROTECTED]> AuthorDate: Wed Nov 14 17:00:41 2007 -0800 > > Committer: Linus Torvalds <[EMAIL PROTECTED]> > > CommitDate: Wed Nov 14 18:45:44 2007 -0800 > > > > x86: disable preemption in delay_tsc() > > > > Marin Mitov points out that delay_tsc() can misbehave if it is > > preempted and rescheduled on a different CPU which has a skewed TSC. > > Fix it by disabling preemption. > > > > this worries me.. this appears to effectively disable preemption during > udelay() and mdelay() loops... which are very obvious latency inducers. > > Now you can argue that if you're preemptible you should have used > msleep() and co, and I'll totally buy that. > > > Maybe we should just check if we're still on the same cpu or something, > or have a cheap way to pin a process to a cpu but both are longer > term solutions. > Yes, we can do better. But this bug can cause very rare failures in probably a large number of device drivers on a minorty of machines. Ugly. So I felt it best to plug it fast while people think about more sophisticated fixes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
On Fri, 16 Nov 2007 02:28:09 +0100 (CET) Roman Zippel wrote:
> Hi,
>
> On Thu, 15 Nov 2007, Sam Ravnborg wrote:
>
> > You suggest just to check ARCH value and not apply your patch. This was
> > not my initial understanding as was hopefully obvious from my reply.
>
> This patch only adds some extra features.
>
> > If user did NOT specify ARCH we should use the kernel configuration - which
> > your solution fail to do.
>
> To make this easy I attached the patch which reverts the problematic
> changes and then you only need this simple change to force the 64BIT value
> for ARCH={i386,x86_64}, otherwise it's set by the user:
Roman,
This all began (AFAIK) because some of us want to continue to be
able to specify ARCH={i386,x86_64} on the (make) command line --
not by using a .config file. Taking away ARCH= on the command line
is a regression (in some minds, at least), so Sam provided that
capability. Is that capability still present after this patch?
Thanks.
> bye, Roman
>
> Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
>
> ---
> Makefile |3 ++-
> arch/x86/Kconfig |4 ++--
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> Index: linux-2.6/Makefile
> ===
> --- linux-2.6.orig/Makefile
> +++ linux-2.6/Makefile
> @@ -165,7 +165,8 @@ export srctree objtree VPATH TOPDIR
> # then ARCH is assigned, getting whatever value it gets normally, and
> # SUBARCH is subsequently ignored.
>
> -SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
> +SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> + -e s/sun4u/sparc64/ \
> -e s/arm.*/arm/ -e s/sa110/arm/ \
> -e s/s390x/s390/ -e s/parisc64/parisc/ \
> -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> Index: linux-2.6/arch/x86/Kconfig
> ===
> --- linux-2.6.orig/arch/x86/Kconfig
> +++ linux-2.6/arch/x86/Kconfig
> @@ -3,8 +3,8 @@ mainmenu "Linux Kernel Configuration for
>
> # Select 32 or 64 bit
> config 64BIT
> - bool "64-bit kernel"
> - default n
> + bool "64-bit kernel" if ARCH="x86"
> + default ARCH="x86_64"
> help
> Say yes to build a 64-bit kernel - formerly known as x86_64
> Say no to build a 32-bit kernel - formerly known as i386
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-rt1
On Thu, 15 Nov 2007, Mark Knecht wrote: > On Nov 15, 2007 10:40 AM, Steven Rostedt <[EMAIL PROTECTED]> wrote: > > Finally! > > > > We are pleased to announce 2.6.24-rc2-rt1. > > > > > Hi Steve, >Not sure I've ever posted on this list. Always looking to help out > at my low level. > >Anyway, I tried building the kernel. My 1st two attempts, done > running make menuconfig from scratch, didn't boot. I gave up on that > for now and tried using make oldconfig from my 2.6.23-rt1 kernel (I'm > so far behind!!) and ended up with this error. Not sure it's enough > for you to find the bug. If you want/need more or want the config file > let me know. > >I'm sure this is just me setting inappropriate bits but I figured I > might as well send along the info. >/dev/null if it's inappropriate > but let me know how to move forward if possible. > >As always thanks the the rt-kernel team for all you do. > > Cheers, > Mark > > CC ipc/mqueue.o > CC ipc/compat_mq.o > LD ipc/built-in.o > CC security/security.o > CC security/dummy.o > CC security/inode.o > LD security/built-in.o > CC [M] security/commoncap.o > CC [M] security/realcap.o > security/realcap.c: In function 'realtime_exit': > security/realcap.c:129: error: implicit declaration of function > 'mod_unreg_security' > security/realcap.c:133: error: implicit declaration of function > 'unregister_security' > make[1]: *** [security/realcap.o] Error 1 > make: *** [security] Error 2 > lightning linux # Hi Mark, I guess you enabled the realtime capabilities (Realtime-LSM - Obsolete -) You could disable that, and try again. I'm not sending a fix (yet) because ... Ingo, Do we still need to have the realtime-lsm.patch? It has been considered obsolete for over a year now. Can we finally remove it. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86: disable preemption in delay_tsc()
On Thu, 15 Nov 2007 04:00:47 GMT Linux Kernel Mailing List wrote: > Gitweb: > http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=35d5d08a085c56f153458c3f5d8ce24123617faf > Commit: 35d5d08a085c56f153458c3f5d8ce24123617faf Parent: > 7eea436433b7b18045f272562e256976f593f7c0 Author: Andrew Morton > <[EMAIL PROTECTED]> AuthorDate: Wed Nov 14 17:00:41 2007 -0800 > Committer: Linus Torvalds <[EMAIL PROTECTED]> > CommitDate: Wed Nov 14 18:45:44 2007 -0800 > > x86: disable preemption in delay_tsc() > > Marin Mitov points out that delay_tsc() can misbehave if it is > preempted and rescheduled on a different CPU which has a skewed TSC. > Fix it by disabling preemption. > this worries me.. this appears to effectively disable preemption during udelay() and mdelay() loops... which are very obvious latency inducers. Now you can argue that if you're preemptible you should have used msleep() and co, and I'll totally buy that. Maybe we should just check if we're still on the same cpu or something, or have a cheap way to pin a process to a cpu but both are longer term solutions. -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NET]: rt_check_expire() can take a long time, add a cond_resched()
On Thu, 15 Nov 2007 04:01:48 GMT
Linux Kernel Mailing List wrote:
> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=d90bf5a976793edfa88d3bb2393f0231eb8ce1e5
> Commit: d90bf5a976793edfa88d3bb2393f0231eb8ce1e5 Parent:
> 66ba886254edbbd9442d30f1eef6f6fb0145027d Author: Eric Dumazet
> <[EMAIL PROTECTED]> AuthorDate: Wed Nov 14 16:14:05 2007 -0800
> Committer: David S. Miller <[EMAIL PROTECTED]>
> CommitDate: Wed Nov 14 16:14:05 2007 -0800
>
> [NET]: rt_check_expire() can take a long time, add a
> cond_resched()
> On commit 39c90ece7565f5c47110c2fa77409d7a9478bd5b:
> When the IP route cache is big, rt_check_expire() can take a long
> time to run. (default settings : 20% of the hash table is scanned at
> each invocation)
>
> Adding cond_resched() helps giving cpu to higher priority tasks if
> necessary.
>
> Using a "if (need_resched())" test before calling
> "cond_resched();" is necessary to avoid spending too much time doing
> the resched check.
int __sched cond_resched(void)
{
if (need_resched() && .
somehow I wonder why the second if() is useful at all; it's another
spot for a branch predictor to miss... and a void function call is
really really cheap...
--
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch 3/4] Add HAVE_KPROBES
Linus: On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Changelog: Actually, I know I gave this as the magic incantation, but now that I see it, I realize that I should have told you to just use config KPROBES_SUPPORT def_bool y instead, which is a bit denser. We seem to use both kinds of syntax for these things, but this is really what "def_bool" is there for... - Use HAVE_KPROBES - Use a select - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/avr32/Kconfig |1 + arch/ia64/Kconfig |1 + arch/powerpc/Kconfig |1 + arch/ppc/Kconfig |1 + arch/s390/Kconfig |1 + arch/sparc64/Kconfig |1 + arch/x86/Kconfig |1 + kernel/Kconfig.instrumentation |5 - 8 files changed, 11 insertions(+), 1 deletion(-) Index: linux-2.6-lttng/arch/avr32/Kconfig === --- linux-2.6-lttng.orig/arch/avr32/Kconfig 2007-11-15 21:18:40.0 -0500 +++ linux-2.6-lttng/arch/avr32/Kconfig 2007-11-15 21:24:51.0 -0500 @@ -11,6 +11,7 @@ config AVR32 # With EMBEDDED=n, we get lots of stuff automatically selected # that we usually don't need on AVR32. select EMBEDDED + select HAVE_KPROBES help AVR32 is a high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular Index: linux-2.6-lttng/arch/ia64/Kconfig === --- linux-2.6-lttng.orig/arch/ia64/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/ia64/Kconfig 2007-11-15 21:33:43.0 -0500 @@ -16,6 +16,7 @@ config IA64 select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI select HAVE_OPROFILE + select HAVE_KPROBES default y help The Itanium Processor Family is Intel's 64-bit successor to Index: linux-2.6-lttng/arch/powerpc/Kconfig === --- linux-2.6-lttng.orig/arch/powerpc/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/powerpc/Kconfig2007-11-15 21:33:43.0 -0500 @@ -80,6 +80,7 @@ config PPC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config EARLY_PRINTK bool Index: linux-2.6-lttng/arch/ppc/Kconfig === --- linux-2.6-lttng.orig/arch/ppc/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/ppc/Kconfig2007-11-15 21:33:43.0 -0500 @@ -43,6 +43,7 @@ config PPC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config PPC32 bool Index: linux-2.6-lttng/arch/s390/Kconfig === --- linux-2.6-lttng.orig/arch/s390/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/s390/Kconfig 2007-11-15 21:33:43.0 -0500 @@ -52,6 +52,7 @@ mainmenu "Linux Kernel Configuration" config S390 def_bool y select HAVE_OPROFILE + select HAVE_KPROBES source "init/Kconfig" Index: linux-2.6-lttng/arch/sparc64/Kconfig === --- linux-2.6-lttng.orig/arch/sparc64/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/sparc64/Kconfig2007-11-15 21:33:43.0 -0500 @@ -9,6 +9,7 @@ config SPARC bool default y select HAVE_OPROFILE + select HAVE_KPROBES config SPARC64 bool Index: linux-2.6-lttng/kernel/Kconfig.instrumentation === --- linux-2.6-lttng.orig/kernel/Kconfig.instrumentation 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/kernel/Kconfig.instrumentation 2007-11-15 21:33:43.0 -0500 @@ -35,7 +35,7 @@ config HAVE_OPROFILE config KPROBES bool "Kprobes" depends on KALLSYMS &&
[patch 4/4] Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig
Move the instrumentation Kconfig to arch/Kconfig for architecture dependent options - oprofile - kprobes and init/Kconfig for architecture independent options - profiling - markers Remove the "Instrumentation Support" menu. Everything moves to "General setup". Delete the kernel/Kconfig.instrumentation file. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig | 28 arch/alpha/Kconfig |2 - arch/arm/Kconfig |2 - arch/blackfin/Kconfig |2 - arch/cris/Kconfig |2 - arch/frv/Kconfig |2 - arch/h8300/Kconfig |2 - arch/ia64/Kconfig |2 - arch/m32r/Kconfig |2 - arch/m68k/Kconfig |2 - arch/m68knommu/Kconfig |2 - arch/mips/Kconfig |2 - arch/parisc/Kconfig|2 - arch/powerpc/Kconfig |2 - arch/ppc/Kconfig |2 - arch/s390/Kconfig |2 - arch/sh/Kconfig|2 - arch/sh64/Kconfig |2 - arch/sparc/Kconfig |2 - arch/sparc64/Kconfig |2 - arch/um/Kconfig|2 - arch/v850/Kconfig |2 - arch/x86/Kconfig |2 - arch/xtensa/Kconfig|2 - init/Kconfig | 12 kernel/Kconfig.instrumentation | 55 - 26 files changed, 40 insertions(+), 101 deletions(-) Index: linux-2.6-lttng/arch/Kconfig === --- linux-2.6-lttng.orig/arch/Kconfig 2007-11-15 22:11:34.0 -0500 +++ linux-2.6-lttng/arch/Kconfig2007-11-15 22:16:09.0 -0500 @@ -1,3 +1,31 @@ # # General architecture dependent options # + +config OPROFILE + tristate "OProfile system profiling (EXPERIMENTAL)" + depends on PROFILING + depends on HAVE_OPROFILE + help + OProfile is a profiling system capable of profiling the + whole system, include the kernel, kernel modules, libraries, + and applications. + + If unsure, say N. + +config HAVE_OPROFILE + def_bool n + +config KPROBES + bool "Kprobes" + depends on KALLSYMS && MODULES + depends on HAVE_KPROBES + help + Kprobes allows you to trap at almost any kernel address and + execute a callback function. register_kprobe() establishes + a probepoint and specifies the callback. Kprobes is useful + for kernel debugging, non-intrusive instrumentation and testing. + If in doubt, say "N". + +config HAVE_KPROBES + def_bool n Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-15 22:11:34.0 -0500 +++ linux-2.6-lttng/init/Kconfig2007-11-15 22:15:27.0 -0500 @@ -649,6 +649,18 @@ config SLOB endchoice +config PROFILING + bool "Profiling support (EXPERIMENTAL)" + help + Say Y here to enable the extended profiling support mechanisms used + by profilers such as OProfile. + +config MARKERS + bool "Activate markers" + help + Place an empty function call at each marker site. Can be + dynamically changed for a probe function. + source "arch/Kconfig" endmenu# General setup Index: linux-2.6-lttng/arch/alpha/Kconfig === --- linux-2.6-lttng.orig/arch/alpha/Kconfig 2007-11-15 22:15:16.0 -0500 +++ linux-2.6-lttng/arch/alpha/Kconfig 2007-11-15 22:15:27.0 -0500 @@ -655,8 +655,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/alpha/Kconfig.debug" # DUMMY_CONSOLE may be defined in drivers/video/console/Kconfig Index: linux-2.6-lttng/arch/arm/Kconfig === --- linux-2.6-lttng.orig/arch/arm/Kconfig 2007-11-15 22:15:16.0 -0500 +++ linux-2.6-lttng/arch/arm/Kconfig2007-11-15 22:15:27.0 -0500 @@ -1071,8 +1071,6 @@ endmenu source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - source "arch/arm/Kconfig.debug" source "security/Kconfig" Index: linux-2.6-lttng/arch/blackfin/Kconfig === --- linux-2.6-lttng.orig/arch/blackfin/Kconfig 2007-11-15 22:15:16.0 -0500 +++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-11-15 22:15:27.0 -0500 @@ -1074,8 +1074,6 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "kernel/Kconfig.instrumentation" - menu "Kernel hacking" source "lib/Kconfig.debug" Index: linux-2.6-lttng/arch/cris/Kconfig
[patch 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool "bla bla" config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_ Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/4] Add HAVE_OPROFILE
Linus: On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Changelog: Actually, I know I gave this as the magic incantation, but now that I see it, I realize that I should have told you to just use config ARCH_SUPPORTS_KPROBES def_bool y instead, which is a bit denser. We seem to use both kinds of syntax for these things, but this is really what "def_bool" is there for... - Use ARCH_HAS_* instead of ARCH_SUPPORTS). - Use a select ARCH_HAS_* - Yet another update : Moving to HAVE_* now. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/alpha/Kconfig |1 + arch/arm/Kconfig |1 + arch/blackfin/Kconfig |1 + arch/ia64/Kconfig |1 + arch/m32r/Kconfig |1 + arch/mips/Kconfig |1 + arch/parisc/Kconfig|1 + arch/powerpc/Kconfig |1 + arch/ppc/Kconfig |1 + arch/s390/Kconfig |1 + arch/sh/Kconfig|1 + arch/sh64/Kconfig |1 + arch/sparc/Kconfig |1 + arch/sparc64/Kconfig |1 + arch/x86/Kconfig |1 + kernel/Kconfig.instrumentation |5 - 16 files changed, 19 insertions(+), 1 deletion(-) Index: linux-2.6-lttng/arch/alpha/Kconfig === --- linux-2.6-lttng.orig/arch/alpha/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/alpha/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -5,6 +5,7 @@ config ALPHA bool default y + select HAVE_OPROFILE help The Alpha is a 64-bit general-purpose processor designed and marketed by the Digital Equipment Corporation of blessed memory, Index: linux-2.6-lttng/arch/arm/Kconfig === --- linux-2.6-lttng.orig/arch/arm/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/arm/Kconfig2007-11-15 21:23:35.0 -0500 @@ -10,6 +10,7 @@ config ARM default y select RTC_LIB select SYS_SUPPORTS_APM_EMULATION + select HAVE_OPROFILE help The ARM series is a line of low-power-consumption RISC chip designs licensed by ARM Ltd and targeted at embedded applications and Index: linux-2.6-lttng/arch/blackfin/Kconfig === --- linux-2.6-lttng.orig/arch/blackfin/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -24,6 +24,7 @@ config RWSEM_XCHGADD_ALGORITHM config BLACKFIN bool default y + select HAVE_OPROFILE config ZONE_DMA bool Index: linux-2.6-lttng/arch/ia64/Kconfig === --- linux-2.6-lttng.orig/arch/ia64/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/ia64/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -15,6 +15,7 @@ config IA64 select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI + select HAVE_OPROFILE default y help The Itanium Processor Family is Intel's 64-bit successor to Index: linux-2.6-lttng/arch/m32r/Kconfig === --- linux-2.6-lttng.orig/arch/m32r/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/m32r/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -8,6 +8,7 @@ mainmenu "Linux/M32R Kernel Configuratio config M32R bool default y + select HAVE_OPROFILE config SBUS bool Index: linux-2.6-lttng/arch/mips/Kconfig === --- linux-2.6-lttng.orig/arch/mips/Kconfig 2007-11-15 21:18:40.0 -0500 +++ linux-2.6-lttng/arch/mips/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -1,6 +1,7 @@ config MIPS bool default y + select HAVE_OPROFILE # Horrible source of confusion. Die, die, die ...
[patch 0/4] Instrumentation menu removal (HAVE_* form)
Should hopefully be the final form. Please wait 1-2 days before merge, just in case Sam changes his mind ;) Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix a deadlock in set_rtc_mmss()
Aristeu Rozanski wrote: > Hello Dan, >> Patch is valid only for 2.6.23.x, guessing from the recent arch/ changes >> in 2.6.24-rc. >> >> set_rtc_mmss() was used to be called from interrupt context in 2.6.22, >> however in 2.6.23, it is called from a timer context, where interrupts >> are enabled. This patch ensures that rtc_interrupt() won't dead-lock >> with set_rtc_mmss(). > >> diff --git a/arch/x86_64/kernel/time.c b/arch/x86_64/kernel/time.c >> index 6241b50..8414236 100644 >> --- a/arch/x86_64/kernel/time.c >> +++ b/arch/x86_64/kernel/time.c >> @@ -87,13 +87,14 @@ static int set_rtc_mmss(unsigned long nowtime) >> int retval = 0; >> int real_seconds, real_minutes, cmos_minutes; >> unsigned char control, freq_select; >> +unsigned long flags; >> >> /* >> * IRQs are disabled when we're called from the timer interrupt, >> * no need for spin_lock_irqsave() >> */ >> >> -spin_lock(_lock); >> +spin_lock_irqsave(_lock, flags); > I think it's a good idea to update or just remove the comment above. > David P. Reed has sent a patch to fix this bug before you. http://lkml.org/lkml/2007/11/14/435 Li Zefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mm creation/destruction hooks
On Thu, Nov 15, 2007 at 04:22:14PM -0800, Jeremy Fitzhardinge wrote: > activate_mm() does that. Yup, which I realized ~10 seconds after sending mail... Oh well. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] UML - Remove unused variables in the context switcher
On Thu, Nov 15, 2007 at 04:15:21PM -0800, Andrew Morton wrote: > I assumed from the above that Karol was the author of this patch. Please > let me know if that was wrong. He is - I forgot the From line... Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
On Thu, 15 Nov 2007, David Miller wrote: > > There is no assembly code required. I overdid it in the patch that I sent > > you trying to make sparc64 use large mappings like x86_64 NUMA. You really > > do not need that. Look at the IA64 and i386 configurations. There is no C > > code required. The x86_64 code only adds some special C code for the NUMA > > case. > > Ok, and like I said last time, I'll examine this more closely > when you spin your next version of these patches. All the above statements are about the version of the patch that I thought you had a look at. > Please post them soon as I'm eager to test this stuff out for > you. Ok. Thanks. (You could test it with the current version Just edit Kconfig and try a few things and I could include the settings in the next release.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Thu, 15 Nov 2007 19:10:15 -0800 (PST) > On Thu, 15 Nov 2007, David Miller wrote: > > > > I have not looked at sparc32 sorry. If you simply set up a couple of > > > configuration values in arch/sparc32/Kconfig then everything will be fine. > > > > There is assembler code to write, which as I stated several > > times nobody is going to work on or test. > > There is no assembly code required. I overdid it in the patch that I sent > you trying to make sparc64 use large mappings like x86_64 NUMA. You really > do not need that. Look at the IA64 and i386 configurations. There is no C > code required. The x86_64 code only adds some special C code for the NUMA > case. Ok, and like I said last time, I'll examine this more closely when you spin your next version of these patches. Please post them soon as I'm eager to test this stuff out for you. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/4] x86 support for sys_indirect
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Dumazet wrote: > I am not sure how compat is handled ? (ie running a 32bit task in a > 64bit kernel) I already mentioned that I have a patch here. I'll test it first, though. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHPQtU2ijCOnn/RHQRAqRYAKCA6x79xzmYxS0WjdoB29+1bIcP4gCgpAj3 VmOkji7I1Ec+FaMeLSf1fSA= =7jn7 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
On Thu, 15 Nov 2007, David Miller wrote: > > I have not looked at sparc32 sorry. If you simply set up a couple of > > configuration values in arch/sparc32/Kconfig then everything will be fine. > > There is assembler code to write, which as I stated several > times nobody is going to work on or test. There is no assembly code required. I overdid it in the patch that I sent you trying to make sparc64 use large mappings like x86_64 NUMA. You really do not need that. Look at the IA64 and i386 configurations. There is no C code required. The x86_64 code only adds some special C code for the NUMA case. > > All MMU platforms can use the virtual mappings. The main use of the static > > configuration is for embedded systems. > > Someone has to implement and test VMEMMAP now on all of these > architectures, it is becomming a requirement unlike in the sparsemem > patches case where it was optional. > > That's unreasonable. VMEMMAP is something different from the cpu allocator. All MMU platforms have vmalloc support and you even suggested the use of vmalloc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch] Fix UML broken (was Re: User Mode Linux still broken in 2.6.23.1)
On Thu, Nov 15, 2007 at 01:06:08PM -0800, Greg KH wrote: >On Thu, Nov 15, 2007 at 02:57:21PM -0600, Rob Landley wrote: >> On Thursday 15 November 2007 00:02:55 Greg KH wrote: >> > On Wed, Nov 14, 2007 at 11:58:15PM -0600, Rob Landley wrote: >> > > On Wednesday 14 November 2007 12:54:44 Greg KH wrote: >> > > > On Sat, Nov 03, 2007 at 11:51:50PM -0500, Rob Landley wrote: >> > > > > Building with the attached .config on x86-64, it does this: >> > > > > >> > > > > CC arch/um/kernel/smp.o >> > > > > In file included from include/asm/arch/tlb.h:11, >> > > > > from include/asm/tlb.h:4, >> > > > > from arch/um/kernel/smp.c:8: >> > > > > include/asm-generic/tlb.h: In function ???tlb_flush_mmu???: >> > > > > include/asm-generic/tlb.h:76: error: implicit declaration of function >> > > > > ???release_pages??? include/asm-generic/tlb.h: In function >> > > > > ???tlb_remove_page???: >> > > > > include/asm-generic/tlb.h:105: error: implicit declaration of >> > > > > function ???page_cache_release??? make[1]: *** [arch/um/kernel/smp.o] >> > > > > Error 1 make: *** [arch/um/kernel] Error 2 >> > > > > >> > > > > I've been doing the following to fix it. I know it's not the right >> > > > > fix, (see the earlier thread about it at >> > > > > http://lkml.org/lkml/2007/8/24/441 ) but could the one line fix go >> > > > > into the -stable queue 2.6.23 while a proper fix goes into 2.6.24? >> > > > >> > > > I think the patches that I have just added to the stable queue for >> > > > 2.6.23.2 will fix this. If not, please let me know after testing. >> > > >> > > Where do I find these patches to test? I know where to find the stable >> > > releases, but not the "stable queue". >> > > >> > > Documentation/stable_kernel_rules.txt just says there _is_ a stable >> > > queue, not where to access it. Google's first hit for "linux stable >> > > queue" was >> > > http://git.kernel.org/?p=linux/kernel/git/chrisw/stable-queue.git;a=short >> > >log which apparently stopped updating in march... >> > > >> > > Happy to test the patch you mentioned, if I can figure out where to find >> > > it... >> > >> > It's at: >> > >> > http://git.kernel.org/?p=linux/kernel/git/stable/stable-queue.git;a=summar >> >y >> > >> > Chris and I used to have separate queues, but that got messy, I suppose >> > we should just delete those old copies... >> >> In a freshly extracted 2.6.23 tarball, I applied the 4 uml-*.patch files >> from >> stable-queue/review-2.6.23-2 in sequence (all applied cleanly), and then did >> the following: >> >> cat > mini.conf << EOF && >> CONFIG_BINFMT_ELF=y >> CONFIG_HOSTFS=y >> CONFIG_LBD=y >> CONFIG_BLK_DEV=y >> CONFIG_BLK_DEV_LOOP=y >> CONFIG_STDERR_CONSOLE=y >> CONFIG_UNIX98_PTYS=y >> CONFIG_EXT2_FS=y >> EOF >> make ARCH=um allnoconfig KCONFIG_ALLCONFIG=mini.conf >> >> Then I did: >> >> make -j 2 ARCH=um >> >> And it still breaks: >> >> CC arch/um/kernel/smp.o >> In file included from include/asm/arch/tlb.h:11, >> from include/asm/tlb.h:4, >> from arch/um/kernel/smp.c:8: >> include/asm-generic/tlb.h: In function ???tlb_flush_mmu???: >> include/asm-generic/tlb.h:76: error: implicit declaration of >> function ???release_pages??? >> include/asm-generic/tlb.h: In function ???tlb_remove_page???: >> include/asm-generic/tlb.h:105: error: implicit declaration of >> function ???page_cache_release??? >> make[1]: *** [arch/um/kernel/smp.o] Error 1 >> make: *** [arch/um/kernel] Error 2 >> make: *** Waiting for unfinished jobs >> >> My .config is attached. > >Hm, not good. I'll let Jeff handle this :) Could you please try this patch? Can it fix the error? Signed-off-by: WANG Cong <[EMAIL PROTECTED]> --- diff --git a/Makefile b/Makefile diff --git a/include/linux/swap.h b/include/linux/swap.h index 4f3838a..2c3ce4c 100644 --- a/include/linux/swap.h +++ b/include/linux/swap.h @@ -6,6 +6,7 @@ #include #include #include +#include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/4] Add ARCH_SUPPORTS_OPROFILE
* Andrew Morton ([EMAIL PROTECTED]) wrote: > On Thu, 15 Nov 2007 21:23:19 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> > wrote: > > > * Andrew Morton ([EMAIL PROTECTED]) wrote: > > > On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> > > > wrote: > > > > > > > arch/x86/Kconfig.i386 |1 + > > > > arch/x86/Kconfig.x86_64|1 + > > > > > > these no longer exist. > > > > Ok, should I prepare a fix or is it duplicated work ? > > I fixed the new patches, then had a go at fixing the thus-broken kprobes > ones and the resulting mess caused me to give up and drop both patchsets. > > Arg.. yet another change of mid from Sam.. he prefers HAVE_* to ARCH_HAS_*. will it ever stop.. ? Please don't merge my previous patchset, I'll resend them. I will adapt them accordingly. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Thu, 15 Nov 2007 18:55:21 -0800 (PST) > On Thu, 15 Nov 2007, David Miller wrote: > > > Sparc32 is still broken, as just one of several possible examples. > > I have not looked at sparc32 sorry. If you simply set up a couple of > configuration values in arch/sparc32/Kconfig then everything will be fine. There is assembler code to write, which as I stated several times nobody is going to work on or test. It is unreasonable to add this new VMEMMAP requirement in order for your patches to work properly. > > The BSS usage is still there for platforms that don't use VMEMMAP. > > All MMU platforms can use the virtual mappings. The main use of the static > configuration is for embedded systems. Someone has to implement and test VMEMMAP now on all of these architectures, it is becomming a requirement unlike in the sparsemem patches case where it was optional. That's unreasonable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 4/4] first use of sys_indirect system call
Ulrich Drepper a écrit : This is a first user of sys_indirect. Several of the socket-related system calls which produce a file handle now can be passed an additional parameter to set the FD_CLOEXEC flag. - retval = sock_map_fd(sock); + retval = sock_map_fd_flags(sock, current->indirect_params.file_flags.flags); Yes, we know now why you wanted sys_indirect so much :) However, there should be a macro or something to ease reader mind... #define INDPARAM(SUBSYSNAME,PARAMNAME) \ (current->indirect_params.##SUBSYSNAME.##PARAMNAME) > + retval = sock_map_fd_flags(sock, INDPARAM(file_flags,flags)); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
On Thu, 15 Nov 2007, David Miller wrote: > If you're talking about the VMEMMAP thing, that patch didn't remove > the problem, it simply added optimizations for sparc64 so that you could > sweep the problem under the rug. The virtual mapping of the cpu areas is used by the patch I posted for i386, ia64 and x86_64. All the ones that I have access to here. > Sparc32 is still broken, as just one of several possible examples. I have not looked at sparc32 sorry. If you simply set up a couple of configuration values in arch/sparc32/Kconfig then everything will be fine. > The BSS usage is still there for platforms that don't use VMEMMAP. All MMU platforms can use the virtual mappings. The main use of the static configuration is for embedded systems. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 1/4] actual sys_indirect code
Ulrich Drepper a écrit :
This is the actual architecture-independent part of the system call
implementation.
+
+long sys_indirect(struct indirect_registers __user *userregs,
+ void __user *userparams, size_t paramslen)
+{
+ struct indirect_registers regs;
+ long result;
+
+ if (copy_from_user(, userregs, sizeof(regs)))
+ return -EFAULT;
+
+ switch (INDIRECT_SYSCALL ())
+ {
+#ifdef __NR_accept
+ case __NR_accept:
+#endif
+#ifdef __NR_socketpair
+ case __NR_socketpair:
+#endif
+#ifdef __NR_socket
+ case __NR_socket:
+#endif
+#ifdef __NR_socketcall
+ case __NR_socketcall:
+#endif
+ break;
+
+ default:
+ return -EINVAL;
+ }
+
+ if (paramslen > sizeof(union indirect_params))
+ return -EINVAL;
+ if (copy_from_user(>indirect_params, userparams, paramslen))
Here, you should clear current->indirect_params before returning -EFAULT
{
memset(>indirect_params, 0, paramslen);
+ return -EFAULT;
}
copy_from_user could do a partial copy (so dirty first bytes of
indirect_params) and all furthers calls to socket()/open() and so on could be
broken.
+
+ result = CALL_INDIRECT();
+
+ memset(>indirect_params, '\0', paramslen);
+
+ return result;
+}
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: x86_64: Make sparsemem/vmemmap the default memory model
On Thu, 15 Nov 2007 18:24:54 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Thu, 15 Nov 2007, Andrew Morton wrote: > > > Unfortunately some loon has gone and merged the i386 and x86_64 Kconfig > > files. I was fixing that up but I worry what effects these Kconfig changes > > might have on, for example, i386 NUMA setups. > > > > So I'll duck this version, sorry. > > Is there a tree that I can rediff the patch against? Mainline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 4/7] LTTng instrumentation kernel
* Mike Mason ([EMAIL PROTECTED]) wrote:
> snip
>> +void list_modules(void *call_data)
>> +{
>> +/* Enumerate loaded modules */
>> +struct list_head*i;
>> +struct module*mod;
>> +unsigned long refcount = 0;
>> +
>> +mutex_lock(_mutex);
>> +list_for_each(i, ) {
>> +mod = list_entry(i, struct module, list);
>> +#ifdef CONFIG_MODULE_UNLOAD
>> +refcount = local_read(>ref[0].count);
>> +#endif
>> +__trace_mark(0, list_module, call_data,
>> +"name %s state %d refcount %lu",
>> +mod->name, mod->state, refcount);
>> +}
>> +mutex_unlock(_mutex);
>> +}
>> +EXPORT_SYMBOL_GPL(list_modules);
>> +
>> /* Given an address, look for it in the module exception tables. */
>> const struct exception_table_entry *search_module_extables(unsigned long
>> addr)
>> {
>
> What is the purpose of list_modules() in this patch? Seems outside the
> scope of the patches' intent. I assume LTTng uses it for some purpose, but
> it's not required to use the markers added by the patch.
>
Right, I should move it down in my patchset.
> Also, if list_modules() remains, the 0 should be removed from
> "__trace_mark(0, ..."
> Mike Mason
With the immediate values based markers, the 0 means an optimized
markers (non-generic). I use __trace_mark directly to be able to pass
the call_data argument.
Thanks for the review,
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] Rename vmcoreinfo's macros returning the size
VMCOREINFO_SIZE() should be renamed VMCOREINFO_STRUCT_SIZE() since it's always
returning the size of the struct with a given name. This change would allow
VMCOREINFO_TYPEDEF_SIZE() to simply become VMCOREINFO_SIZE() since it need not
be used exclusively for typedefs.
This discussion is the following:
http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0582.html
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
Acked-by: David Rientjes <[EMAIL PROTECTED]>
---
diff -rpuN a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
--- a/arch/ia64/kernel/machine_kexec.c 2007-11-14 15:50:10.0 +0900
+++ b/arch/ia64/kernel/machine_kexec.c 2007-11-14 15:50:36.0 +0900
@@ -135,7 +135,7 @@ void arch_crash_save_vmcoreinfo(void)
VMCOREINFO_SYMBOL(node_memblk);
VMCOREINFO_LENGTH(node_memblk, NR_NODE_MEMBLKS);
- VMCOREINFO_SIZE(node_memblk_s);
+ VMCOREINFO_STRUCT_SIZE(node_memblk_s);
VMCOREINFO_OFFSET(node_memblk_s, start_paddr);
VMCOREINFO_OFFSET(node_memblk_s, size);
#endif
diff -rpuN a/include/linux/kexec.h b/include/linux/kexec.h
--- a/include/linux/kexec.h 2007-11-14 15:50:09.0 +0900
+++ b/include/linux/kexec.h 2007-11-14 15:50:36.0 +0900
@@ -131,10 +131,10 @@ unsigned long paddr_vmcoreinfo_note(void
vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long))
#define VMCOREINFO_SIZE(name) \
vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
- (unsigned long)sizeof(struct name))
-#define VMCOREINFO_TYPEDEF_SIZE(name) \
- vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
(unsigned long)sizeof(name))
+#define VMCOREINFO_STRUCT_SIZE(name) \
+ vmcoreinfo_append_str("SIZE(%s)=%lu\n", #name, \
+ (unsigned long)sizeof(struct name))
#define VMCOREINFO_OFFSET(name, field) \
vmcoreinfo_append_str("OFFSET(%s.%s)=%lu\n", #name, #field, \
(unsigned long)&(((struct name *)0)->field))
diff -rpuN a/kernel/kexec.c b/kernel/kexec.c
--- a/kernel/kexec.c2007-11-14 15:50:09.0 +0900
+++ b/kernel/kexec.c2007-11-14 15:50:36.0 +0900
@@ -1376,15 +1376,15 @@ static int __init crash_save_vmcoreinfo_
#ifdef CONFIG_SPARSEMEM
VMCOREINFO_SYMBOL(mem_section);
VMCOREINFO_LENGTH(mem_section, NR_SECTION_ROOTS);
- VMCOREINFO_SIZE(mem_section);
+ VMCOREINFO_STRUCT_SIZE(mem_section);
VMCOREINFO_OFFSET(mem_section, section_mem_map);
#endif
- VMCOREINFO_SIZE(page);
- VMCOREINFO_SIZE(pglist_data);
- VMCOREINFO_SIZE(zone);
- VMCOREINFO_SIZE(free_area);
- VMCOREINFO_SIZE(list_head);
- VMCOREINFO_TYPEDEF_SIZE(nodemask_t);
+ VMCOREINFO_STRUCT_SIZE(page);
+ VMCOREINFO_STRUCT_SIZE(pglist_data);
+ VMCOREINFO_STRUCT_SIZE(zone);
+ VMCOREINFO_STRUCT_SIZE(free_area);
+ VMCOREINFO_STRUCT_SIZE(list_head);
+ VMCOREINFO_SIZE(nodemask_t);
VMCOREINFO_OFFSET(page, flags);
VMCOREINFO_OFFSET(page, _count);
VMCOREINFO_OFFSET(page, mapping);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] Fix the configuration dependencies
This patch fixes the configuration dependencies in the vmcoreinfo data.
i386's "node_data" is defined in arch/x86/mm/discontig_32.c,
and x86_64's one is defined in arch/x86/mm/numa_64.c.
They depend on CONFIG_NUMA:
arch/x86/mm/Makefile_32:7
obj-$(CONFIG_NUMA) += discontig_32.o
arch/x86/mm/Makefile_64:7
obj-$(CONFIG_NUMA) += numa_64.o
ia64's "pgdat_list" is defined in arch/ia64/mm/discontig.c,
and it depends on CONFIG_DISCONTIGMEM and CONFIG_SPARSEMEM:
arch/ia64/mm/Makefile:9-10
obj-$(CONFIG_DISCONTIGMEM) += discontig.o
obj-$(CONFIG_SPARSEMEM)+= discontig.o
ia64's "node_memblk" is defined in arch/ia64/mm/numa.c,
and it depends on CONFIG_NUMA:
arch/ia64/mm/Makefile:8
obj-$(CONFIG_NUMA) += numa.o
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
---
diff -rpuN a/arch/ia64/kernel/machine_kexec.c b/arch/ia64/kernel/machine_kexec.c
--- a/arch/ia64/kernel/machine_kexec.c 2007-11-14 15:39:06.0 +0900
+++ b/arch/ia64/kernel/machine_kexec.c 2007-11-14 15:41:41.0 +0900
@@ -129,10 +129,11 @@ void machine_kexec(struct kimage *image)
void arch_crash_save_vmcoreinfo(void)
{
-#if defined(CONFIG_ARCH_DISCONTIGMEM_ENABLE) && defined(CONFIG_NUMA)
+#if defined(CONFIG_DISCONTIGMEM) || defined(CONFIG_SPARSEMEM)
VMCOREINFO_SYMBOL(pgdat_list);
VMCOREINFO_LENGTH(pgdat_list, MAX_NUMNODES);
-
+#endif
+#ifdef CONFIG_NUMA
VMCOREINFO_SYMBOL(node_memblk);
VMCOREINFO_LENGTH(node_memblk, NR_NODE_MEMBLKS);
VMCOREINFO_STRUCT_SIZE(node_memblk_s);
diff -rpuN a/arch/x86/kernel/machine_kexec_32.c
b/arch/x86/kernel/machine_kexec_32.c
--- a/arch/x86/kernel/machine_kexec_32.c2007-11-14 15:39:19.0
+0900
+++ b/arch/x86/kernel/machine_kexec_32.c2007-11-14 15:39:33.0
+0900
@@ -151,7 +151,7 @@ NORET_TYPE void machine_kexec(struct kim
void arch_crash_save_vmcoreinfo(void)
{
-#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
+#ifdef CONFIG_NUMA
VMCOREINFO_SYMBOL(node_data);
VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
#endif
diff -rpuN a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
--- a/arch/x86/kernel/machine_kexec_64.c2007-11-14 15:39:19.0
+0900
+++ b/arch/x86/kernel/machine_kexec_64.c2007-11-14 15:39:33.0
+0900
@@ -235,7 +235,7 @@ void arch_crash_save_vmcoreinfo(void)
{
VMCOREINFO_SYMBOL(init_level4_pgt);
-#ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE
+#ifdef CONFIG_NUMA
VMCOREINFO_SYMBOL(node_data);
VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);
#endif
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] Add the array length of "free_list" for filtering free pages
This patch adds the array length of "free_area.free_list" to the vmcoreinfo data so that makedumpfile (dump filtering command) can exclude all free pages in linux-2.6.24. makedumpfile creates a small dumpfile by excluding unnecessary pages for the analysis. To distinguish unnecessary pages, makedumpfile gets the vmcoreinfo data which has the minimum debugging information only for dump filtering. In 2.6.24-rc1 or later, the free_area.free_list is an array which has one list for each migrate types instead of a single list. makedumpfile needs the array length of "free_area.free_list" and the vmcoreinfo data should contain it. Signed-off-by: Huang Ying <[EMAIL PROTECTED]> Tested-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]> --- diff -rpuN a/kernel/kexec.c b/kernel/kexec.c --- a/kernel/kexec.c2007-11-12 11:15:26.0 +0900 +++ b/kernel/kexec.c2007-11-12 11:16:09.0 +0900 @@ -1404,6 +1404,7 @@ static int __init crash_save_vmcoreinfo_ VMCOREINFO_OFFSET(list_head, next); VMCOREINFO_OFFSET(list_head, prev); VMCOREINFO_LENGTH(zone.free_area, MAX_ORDER); + VMCOREINFO_LENGTH(free_area.free_list, MIGRATE_TYPES); VMCOREINFO_NUMBER(NR_FREE_PAGES); arch_crash_save_vmcoreinfo(); _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
From: Christoph Lameter <[EMAIL PROTECTED]> Date: Thu, 15 Nov 2007 18:19:37 -0800 (PST) > On Thu, 15 Nov 2007, David Miller wrote: > > > Well, the first version of the patch set, the one I tested, did > > require a lot of BSS space. And that's the one they are writing > > about. > > I am running the same version that you also ran. The problem is that you > did not configure the stuff properly for your box and I did not include a > configuration for sparc64 since I did not know how it needed to be > configured for sparc64. You ignored the patch for sparc64 that I provided > to correct the problem. If you're talking about the VMEMMAP thing, that patch didn't remove the problem, it simply added optimizations for sparc64 so that you could sweep the problem under the rug. Sparc32 is still broken, as just one of several possible examples. The BSS usage is still there for platforms that don't use VMEMMAP. So again, the lwn.net report is accurate. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Document I_SYNC and I_DATASYNC
After some archeology (see http://logfs.org/logfs/inode_state_bits) I
finally figured out what the three I_DIRTY bits do. Maybe others would
prefer less effort to reach this insight.
Signed-off-by: Jörn Engel <[EMAIL PROTECTED]>
---
include/linux/fs.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
--- git_I_DIRTY/include/linux/fs.h~I_DIRTY 2007-11-15 20:51:57.0
+0100
+++ git_I_DIRTY/include/linux/fs.h 2007-11-16 03:45:16.0 +0100
@@ -1276,8 +1276,10 @@ struct super_operations {
*
* Two bits are used for locking and completion notification, I_LOCK and
I_SYNC.
*
- * I_DIRTY_SYNCInode itself is dirty.
- * I_DIRTY_DATASYNCData-related inode changes pending
+ * I_DIRTY_SYNCInode is dirty, but doesn't have to be written
on
+ * fdatasync(). i_atime is the usual cause.
+ * I_DIRTY_DATASYNCInode is dirty and must be written on fdatasync(), f.e.
+ * because i_size changed.
* I_DIRTY_PAGES Inode has dirty pages. Inode itself may be clean.
* I_NEW get_new_inode() sets i_state to I_LOCK|I_NEW. Both
* are cleared by unlock_new_inode(), called from iget().
@@ -1309,8 +1311,6 @@ struct super_operations {
* purpose reduces latency and prevents some filesystem-
* specific deadlocks.
*
- * Q: Why does I_DIRTY_DATASYNC exist? It appears as if it could be replaced
- *by (I_DIRTY_SYNC|I_DIRTY_PAGES).
* Q: What is the difference between I_WILL_FREE and I_FREEING?
* Q: igrab() only checks on (I_FREEING|I_WILL_FREE). Should it also check on
*I_CLEAR? If not, why?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 2/4] x86 support for sys_indirect
Ulrich Drepper a écrit : This part adds support for sys_indirect on x86 and x86-64. arch/x86/ia32/ia32entry.S|1 + b/arch/x86/kernel/syscall_table_32.S |1 + b/include/asm-x86/indirect.h |5 + b/include/asm-x86/indirect_32.h | 23 +++ b/include/asm-x86/indirect_64.h | 24 b/include/asm-x86/unistd_32.h|3 ++- b/include/asm-x86/unistd_64.h|2 ++ 7 files changed, 58 insertions(+), 1 deletion(-) I am not sure how compat is handled ? (ie running a 32bit task in a 64bit kernel) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: High priority tasks break SMP balancer?
On Thu, Nov 15, 2007 at 06:31:49PM -0800, Christoph Lameter wrote: > On Thu, 15 Nov 2007, Micah Dowty wrote: > > > On all kernels I've tested from after your patch was committed, I can > > reproduce a problem where a single high-priority thread which wakes up > > very frequently can artificially inflate the SMP balancer's load > > average for one CPU, causing other tasks to be migrated off that > > CPU. The result is that this high-priority thread (which may only use > > a few percent CPU) gets an entire CPU to itself. Even if there are > > several busy-looping threads running, this CPU will be mostly idle. > > I am a bit at a loss as to how this could relate to the patch. This looks > like a load balance logic issue that causes the load calculation to go > wrong? My best guess is that this has something to do with the timing with which we sample the CPU's instantaneous load when calculating the load averages.. but I still understand only the basics of the scheduler and SMP balancer. All I really know for sure at this point regarding your patch is that git-bisect found it for me. It almost seems like the load average algorithm is ignoring the CPU's idle time, and only accounting for the time that CPU spends running processes. One of the symptoms is that the mostly-idle CPU in my test has an instantaneous load which is usually zero, but a very high load average. (9000, 3, etc.) I want to help get to the bottom of this issue, but I was hoping that someone experienced with the Linux scheduler and SMP balancer would have some insight or some suggestions about what to try next. Thanks, --Micah - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [patch 06/23] Fix SKB_WITH_OVERHEAD calculations.
From: Greg KH <[EMAIL PROTECTED]> Date: Thu, 15 Nov 2007 16:31:02 -0800 > On Thu, Nov 15, 2007 at 03:31:22PM +0800, Herbert Xu wrote: > > On Wed, Nov 14, 2007 at 11:00:39PM -0800, David Miller wrote: > > > > > > I was just about to mention this and what I think we should do > > > instead is keep the SKB_WITH_OVERHEAD calculation fix in there > > > (it fixes a serious bug which users are hitting) and add the > > > fix for the second bug fix this round as well. > > > > > > Therefore, Greg please keep the patch add the following one as it will > > > address all of the issues. > > > > I agree. If the stable team could make an exception for this > > it would be great. > > No problem, I've added this patch to the series right after the above > mentioned one and it will come out in the next release. Thanks a lot Greg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 4/4] Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig
Move the instrumentation Kconfig to arch/Kconfig for architecture dependent options - oprofile - kprobes and init/Kconfig for architecture independent options - profiling - markers Remove the "Instrumentation Support" menu. Everything moves to "General setup". Delete the kernel/Kconfig.instrumentation file. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig | 28 arch/alpha/Kconfig |2 - arch/arm/Kconfig |2 - arch/blackfin/Kconfig |2 - arch/cris/Kconfig |2 - arch/frv/Kconfig |2 - arch/h8300/Kconfig |2 - arch/ia64/Kconfig |2 - arch/m32r/Kconfig |2 - arch/m68k/Kconfig |2 - arch/m68knommu/Kconfig |2 - arch/mips/Kconfig |2 - arch/parisc/Kconfig|2 - arch/powerpc/Kconfig |2 - arch/ppc/Kconfig |2 - arch/s390/Kconfig |2 - arch/sh/Kconfig|2 - arch/sh64/Kconfig |2 - arch/sparc/Kconfig |2 - arch/sparc64/Kconfig |2 - arch/um/Kconfig|2 - arch/v850/Kconfig |2 - arch/x86/Kconfig |2 - arch/xtensa/Kconfig|2 - init/Kconfig | 12 kernel/Kconfig.instrumentation | 55 - 26 files changed, 40 insertions(+), 101 deletions(-) Index: linux-2.6-lttng/arch/Kconfig === --- linux-2.6-lttng.orig/arch/Kconfig 2007-11-15 21:33:42.0 -0500 +++ linux-2.6-lttng/arch/Kconfig2007-11-15 21:35:04.0 -0500 @@ -1,3 +1,31 @@ # # General architecture dependent options # + +config OPROFILE + tristate "OProfile system profiling (EXPERIMENTAL)" + depends on PROFILING + depends on ARCH_HAS_OPROFILE + help + OProfile is a profiling system capable of profiling the + whole system, include the kernel, kernel modules, libraries, + and applications. + + If unsure, say N. + +config ARCH_HAS_OPROFILE + def_bool n + +config KPROBES + bool "Kprobes" + depends on KALLSYMS && MODULES + depends on ARCH_HAS_KPROBES + help + Kprobes allows you to trap at almost any kernel address and + execute a callback function. register_kprobe() establishes + a probepoint and specifies the callback. Kprobes is useful + for kernel debugging, non-intrusive instrumentation and testing. + If in doubt, say "N". + +config ARCH_HAS_KPROBES + def_bool n Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-15 21:33:43.0 -0500 +++ linux-2.6-lttng/init/Kconfig2007-11-15 21:35:04.0 -0500 @@ -649,6 +649,18 @@ config SLOB endchoice +config PROFILING + bool "Profiling support (EXPERIMENTAL)" + help + Say Y here to enable the extended profiling support mechanisms used + by profilers such as OProfile. + +config MARKERS + bool "Activate markers" + help + Place an empty function call at each marker site. Can be + dynamically changed for a probe function. + source "arch/Kconfig" endmenu# General setup Index: linux-2.6-lttng/kernel/Kconfig.instrumentation === --- linux-2.6-lttng.orig/kernel/Kconfig.instrumentation 2007-11-15 21:33:43.0 -0500 +++ /dev/null 1970-01-01 00:00:00.0 + @@ -1,55 +0,0 @@ -menuconfig INSTRUMENTATION - bool "Instrumentation Support" - default y - ---help--- - Say Y here to get to see options related to performance measurement, - system-wide debugging, and testing. This option alone does not add any - kernel code. - - If you say N, all options in this submenu will be skipped and - disabled. If you're trying to debug the kernel itself, go see the - Kernel Hacking menu. - -if INSTRUMENTATION - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - depends on ARCH_HAS_OPROFILE - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -config ARCH_HAS_OPROFILE - def_bool n - -config KPROBES
[patch 2/4] Add ARCH_SUPPORTS_OPROFILE
Linus: On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Changelog: Actually, I know I gave this as the magic incantation, but now that I see it, I realize that I should have told you to just use config ARCH_SUPPORTS_KPROBES def_bool y instead, which is a bit denser. We seem to use both kinds of syntax for these things, but this is really what "def_bool" is there for... - Use ARCH_HAS_* instead of ARCH_SUPPORTS). - Use a select ARCH_HAS_* Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/alpha/Kconfig |1 + arch/arm/Kconfig |1 + arch/blackfin/Kconfig |1 + arch/ia64/Kconfig |1 + arch/m32r/Kconfig |1 + arch/mips/Kconfig |1 + arch/parisc/Kconfig|1 + arch/powerpc/Kconfig |1 + arch/ppc/Kconfig |1 + arch/s390/Kconfig |1 + arch/sh/Kconfig|1 + arch/sh64/Kconfig |1 + arch/sparc/Kconfig |1 + arch/sparc64/Kconfig |1 + arch/x86/Kconfig |1 + kernel/Kconfig.instrumentation |5 - 16 files changed, 19 insertions(+), 1 deletion(-) Index: linux-2.6-lttng/arch/alpha/Kconfig === --- linux-2.6-lttng.orig/arch/alpha/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/alpha/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -5,6 +5,7 @@ config ALPHA bool default y + select ARCH_HAS_OPROFILE help The Alpha is a 64-bit general-purpose processor designed and marketed by the Digital Equipment Corporation of blessed memory, Index: linux-2.6-lttng/arch/arm/Kconfig === --- linux-2.6-lttng.orig/arch/arm/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/arm/Kconfig2007-11-15 21:23:35.0 -0500 @@ -10,6 +10,7 @@ config ARM default y select RTC_LIB select SYS_SUPPORTS_APM_EMULATION + select ARCH_HAS_OPROFILE help The ARM series is a line of low-power-consumption RISC chip designs licensed by ARM Ltd and targeted at embedded applications and Index: linux-2.6-lttng/arch/blackfin/Kconfig === --- linux-2.6-lttng.orig/arch/blackfin/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -24,6 +24,7 @@ config RWSEM_XCHGADD_ALGORITHM config BLACKFIN bool default y + select ARCH_HAS_OPROFILE config ZONE_DMA bool Index: linux-2.6-lttng/arch/ia64/Kconfig === --- linux-2.6-lttng.orig/arch/ia64/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/ia64/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -15,6 +15,7 @@ config IA64 select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI + select ARCH_HAS_OPROFILE default y help The Itanium Processor Family is Intel's 64-bit successor to Index: linux-2.6-lttng/arch/m32r/Kconfig === --- linux-2.6-lttng.orig/arch/m32r/Kconfig 2007-11-15 21:15:48.0 -0500 +++ linux-2.6-lttng/arch/m32r/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -8,6 +8,7 @@ mainmenu "Linux/M32R Kernel Configuratio config M32R bool default y + select ARCH_HAS_OPROFILE config SBUS bool Index: linux-2.6-lttng/arch/mips/Kconfig === --- linux-2.6-lttng.orig/arch/mips/Kconfig 2007-11-15 21:18:40.0 -0500 +++ linux-2.6-lttng/arch/mips/Kconfig 2007-11-15 21:23:35.0 -0500 @@ -1,6 +1,7 @@ config MIPS bool default y + select ARCH_HAS_OPROFILE # Horrible source of confusion. Die, die, die ... select EMBEDDED
[patch 0/4] Instrumentation menu removal, updated to 2.6.24-rc2-git5
Hi Andrew, This patchset should apply flawlessly to 2.6.24-rc2-git5. Sorry again for the inconvenience. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool "bla bla" config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_ Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 3/4] Add ARCH_SUPPORTS_KPROBES
Linus: On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Changelog: Actually, I know I gave this as the magic incantation, but now that I see it, I realize that I should have told you to just use config KPROBES_SUPPORT def_bool y instead, which is a bit denser. We seem to use both kinds of syntax for these things, but this is really what "def_bool" is there for... - Use ARCH_HAS_KPROBES - Use a select Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/avr32/Kconfig |1 + arch/ia64/Kconfig |1 + arch/powerpc/Kconfig |1 + arch/ppc/Kconfig |1 + arch/s390/Kconfig |1 + arch/sparc64/Kconfig |1 + arch/x86/Kconfig |1 + kernel/Kconfig.instrumentation |5 - 8 files changed, 11 insertions(+), 1 deletion(-) Index: linux-2.6-lttng/arch/avr32/Kconfig === --- linux-2.6-lttng.orig/arch/avr32/Kconfig 2007-11-15 21:18:40.0 -0500 +++ linux-2.6-lttng/arch/avr32/Kconfig 2007-11-15 21:24:51.0 -0500 @@ -11,6 +11,7 @@ config AVR32 # With EMBEDDED=n, we get lots of stuff automatically selected # that we usually don't need on AVR32. select EMBEDDED + select ARCH_HAS_KPROBES help AVR32 is a high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular Index: linux-2.6-lttng/arch/ia64/Kconfig === --- linux-2.6-lttng.orig/arch/ia64/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/ia64/Kconfig 2007-11-15 21:33:43.0 -0500 @@ -16,6 +16,7 @@ config IA64 select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES default y help The Itanium Processor Family is Intel's 64-bit successor to Index: linux-2.6-lttng/arch/powerpc/Kconfig === --- linux-2.6-lttng.orig/arch/powerpc/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/powerpc/Kconfig2007-11-15 21:33:43.0 -0500 @@ -80,6 +80,7 @@ config PPC bool default y select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES config EARLY_PRINTK bool Index: linux-2.6-lttng/arch/ppc/Kconfig === --- linux-2.6-lttng.orig/arch/ppc/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/ppc/Kconfig2007-11-15 21:33:43.0 -0500 @@ -43,6 +43,7 @@ config PPC bool default y select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES config PPC32 bool Index: linux-2.6-lttng/arch/s390/Kconfig === --- linux-2.6-lttng.orig/arch/s390/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/s390/Kconfig 2007-11-15 21:33:43.0 -0500 @@ -52,6 +52,7 @@ mainmenu "Linux Kernel Configuration" config S390 def_bool y select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES source "init/Kconfig" Index: linux-2.6-lttng/arch/sparc64/Kconfig === --- linux-2.6-lttng.orig/arch/sparc64/Kconfig 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/arch/sparc64/Kconfig2007-11-15 21:33:43.0 -0500 @@ -9,6 +9,7 @@ config SPARC bool default y select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES config SPARC64 bool Index: linux-2.6-lttng/kernel/Kconfig.instrumentation === --- linux-2.6-lttng.orig/kernel/Kconfig.instrumentation 2007-11-15 21:23:35.0 -0500 +++ linux-2.6-lttng/kernel/Kconfig.instrumentation 2007-11-15 21:33:43.0 -0500 @@ -35,7 +35,7 @@ config ARCH_HAS_OPROFILE config KPROBES bool "Kprobes" depends on
[PATCH 2/5] Use the existing offsetof() for VMCOREINFO_OFFSET()
It is better that the existing offsetof() is used for VMCOREINFO_OFFSET().
This discussion is the following:
http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0584.html
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
---
diff -rpuN a/include/linux/kexec.h b/include/linux/kexec.h
--- a/include/linux/kexec.h 2007-11-12 11:03:31.0 +0900
+++ b/include/linux/kexec.h 2007-11-12 11:03:43.0 +0900
@@ -137,7 +137,7 @@ unsigned long paddr_vmcoreinfo_note(void
(unsigned long)sizeof(struct name))
#define VMCOREINFO_OFFSET(name, field) \
vmcoreinfo_append_str("OFFSET(%s.%s)=%lu\n", #name, #field, \
- (unsigned long)&(((struct name *)0)->field))
+ (unsigned long)offsetof(struct name, field))
#define VMCOREINFO_LENGTH(name, value) \
vmcoreinfo_append_str("LENGTH(%s)=%lu\n", #name, (unsigned long)value)
#define VMCOREINFO_NUMBER(name) \
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] Add "VMCOREINFO_" to all the call for vmcoreinfo_append_str()
For readability, all the calls to vmcoreinfo_append_str() are changed to macros
having a prefix "VMCOREINFO_".
This discussion is the following:
http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0584.html
Signed-off-by: Ken'ichi Ohmichi <[EMAIL PROTECTED]>
---
diff -rpuN a/include/linux/kexec.h b/include/linux/kexec.h
--- a/include/linux/kexec.h 2007-11-12 11:04:09.0 +0900
+++ b/include/linux/kexec.h 2007-11-12 11:04:22.0 +0900
@@ -127,6 +127,10 @@ void vmcoreinfo_append_str(const char *f
__attribute__ ((format (printf, 1, 2)));
unsigned long paddr_vmcoreinfo_note(void);
+#define VMCOREINFO_OSRELEASE(name) \
+ vmcoreinfo_append_str("OSRELEASE=%s\n", #name)
+#define VMCOREINFO_PAGESIZE(value) \
+ vmcoreinfo_append_str("PAGESIZE=%ld\n", value)
#define VMCOREINFO_SYMBOL(name) \
vmcoreinfo_append_str("SYMBOL(%s)=%lx\n", #name, (unsigned long))
#define VMCOREINFO_SIZE(name) \
diff -rpuN a/kernel/kexec.c b/kernel/kexec.c
--- a/kernel/kexec.c2007-11-12 11:04:11.0 +0900
+++ b/kernel/kexec.c2007-11-12 11:04:22.0 +0900
@@ -1361,8 +1361,8 @@ unsigned long __attribute__ ((weak)) pad
static int __init crash_save_vmcoreinfo_init(void)
{
- vmcoreinfo_append_str("OSRELEASE=%s\n", init_uts_ns.name.release);
- vmcoreinfo_append_str("PAGESIZE=%ld\n", PAGE_SIZE);
+ VMCOREINFO_OSRELEASE(init_uts_ns.name.release);
+ VMCOREINFO_PAGESIZE(PAGE_SIZE);
VMCOREINFO_SYMBOL(init_uts_ns);
VMCOREINFO_SYMBOL(node_online_map);
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: High priority tasks break SMP balancer?
On Thu, 15 Nov 2007, Micah Dowty wrote: > On all kernels I've tested from after your patch was committed, I can > reproduce a problem where a single high-priority thread which wakes up > very frequently can artificially inflate the SMP balancer's load > average for one CPU, causing other tasks to be migrated off that > CPU. The result is that this high-priority thread (which may only use > a few percent CPU) gets an entire CPU to itself. Even if there are > several busy-looping threads running, this CPU will be mostly idle. I am a bit at a loss as to how this could relate to the patch. This looks like a load balance logic issue that causes the load calculation to go wrong? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] vmcoreinfo patches for linux-2.6.24-rc3
Hi, This patchset is for the vmcoreinfo data. The vmcoreinfo data has the minimum debugging information only for dump filtering. makedumpfile (dump filtering command) gets it to distinguish unnecessary pages, and makedumpfile creates a small dumpfile. [PATCH 1/5] Rename vmcoreinfo's macros returning the size [PATCH 2/5] Use the existing offsetof() for VMCOREINFO_OFFSET() [PATCH 3/5] Add "VMCOREINFO_" to all the call for vmcoreinfo_append_str() [PATCH 4/5] Fix the configuration dependencies [PATCH 5/5] Add the array length of "free_list" for filtering free pages Patch 1-3 are cleanup patches, and they are the same as I sent before: http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0582.html http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0584.html http://www.ussg.iu.edu/hypermail/linux/kernel/0709.3/0586.html Patch 4 is a new patch for fixing the configuration dependencies. Patch 5 is a new patch for filtering free pages of linux-2.6.24. Their details are explained in each patch. I confirmed that their coding styles are right by checkpatch.pl and tested them on my i386, x86_64 and ia64. Thanks Ken'ichi Ohmichi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/4] Add ARCH_SUPPORTS_OPROFILE
On Thu, 15 Nov 2007 21:23:19 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > * Andrew Morton ([EMAIL PROTECTED]) wrote: > > On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> > > wrote: > > > > > arch/x86/Kconfig.i386 |1 + > > > arch/x86/Kconfig.x86_64|1 + > > > > these no longer exist. > > Ok, should I prepare a fix or is it duplicated work ? I fixed the new patches, then had a go at fixing the thus-broken kprobes ones and the resulting mess caused me to give up and drop both patchsets. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Patch] kernel/exit.c: Fix use-before-check in exit_mm()
On Fri, Nov 16, 2007 at 01:34:54AM +0100, Jesper Juhl wrote:
>On 13/11/2007, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>> Jesper Juhl wrote:
>> > In kernel/exit.c we have this code :
>> >
>> > static void exit_mm(struct task_struct * tsk)
>> > {
>> > struct mm_struct *mm = tsk->mm;
>> >
>> > mm_release(tsk, mm);
>> > if (!mm)
>> > return;
>> > ...
>> >
>> >
>> > But, mm_release() may dereference it's second argument ('mm'), so
>> > shouldn't we be doing the "!mm" test *before* we call mm_release() and
>> > not after?
>> > I don't know the mm code well enough to be able to tell if some of the
>> > other stuff mm_release does needs to be done always and the mm
>> > dereference can't actually happen, but maybe someone else who knows
>> > the code better can tell... In any case, what's currently there looks
>> > a little shaky..
>> >
>>
>> Yeah, it looks wrong. mm_release() calls deactivate_mm() as its first
>> act, which could well dereference mm (though it often doesn't).
>>
>So, whould simply moving the !mm check up as the first in the function
>be an appropriate way to deal with this?
I think yes. Patch below.
Fix use-before-check in kernel/exit.c
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
diff --git a/kernel/exit.c b/kernel/exit.c
index cd0f1d4..dca1e0d 100644
--- a/kernel/exit.c
+++ b/kernel/exit.c
@@ -558,9 +558,9 @@ static void exit_mm(struct task_struct * tsk)
{
struct mm_struct *mm = tsk->mm;
- mm_release(tsk, mm);
if (!mm)
return;
+ mm_release(tsk, mm);
/*
* Serialize with any possible pending coredump.
* We must hold mmap_sem around checking core_waiters
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 4/7] LTTng instrumentation kernel
* Mike Mason ([EMAIL PROTECTED]) wrote:
> This patch uses _trace_mark in lockdep.c and printk.c. I assume they
> should be trace_mark (no '_' prefix).
>
Since it folows the markers with immediate values patch, it requires to
use the underscored version, because the lockdep code can be called from
the return from trap (thus breakpoint) because of the interrupt enable
instrumentation and therefore cause a recursive trap.
The underscored version means "don't use the optimized version".
Mathieu
> Mike Mason
>
>
> Mathieu Desnoyers wrote:
>
> Core kernel events.
>
> *not* present in this patch because they are architecture specific :
> - syscall entry/exit
> - traps
> - kernel thread creation
>
> Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]>
> ---
> include/linux/module.h |1 +
> kernel/exit.c |5 +
> kernel/fork.c |4
> kernel/irq/handle.c|6 ++
> kernel/itimer.c| 11 +++
> kernel/kthread.c |4
> kernel/lockdep.c | 19 +++
> kernel/module.c| 25 +
> kernel/printk.c| 26 ++
> kernel/sched.c | 11 +++
> kernel/signal.c|2 ++
> kernel/softirq.c | 22 ++
> kernel/timer.c | 12 +++-
> 13 files changed, 147 insertions(+), 1 deletion(-)
>
> Index: linux-2.6-lttng/kernel/irq/handle.c
> ===
> --- linux-2.6-lttng.orig/kernel/irq/handle.c 2007-11-13 09:25:27.0
> -0500
> +++ linux-2.6-lttng/kernel/irq/handle.c 2007-11-13 09:49:33.0
> -0500
> @@ -130,6 +130,10 @@ irqreturn_t handle_IRQ_event(unsigned in
> {
> irqreturn_t ret, retval = IRQ_NONE;
> unsigned int status = 0;
> + struct pt_regs *regs = get_irq_regs();
> +
> + trace_mark(kernel_irq_entry, "irq_id %u kernel_mode %u", irq,
> + (regs)?(!user_mode(regs)):(1));
>
> handle_dynamic_tick(action);
>
> @@ -148,6 +152,8 @@ irqreturn_t handle_IRQ_event(unsigned in
> add_interrupt_randomness(irq);
> local_irq_disable();
>
> + trace_mark(kernel_irq_exit, MARK_NOARGS);
> +
> return retval;
> }
>
> Index: linux-2.6-lttng/kernel/itimer.c
> ===
> --- linux-2.6-lttng.orig/kernel/itimer.c 2007-11-13 09:25:27.0
> -0500
> +++ linux-2.6-lttng/kernel/itimer.c 2007-11-13 09:49:33.0 -0500
> @@ -132,6 +132,8 @@ enum hrtimer_restart it_real_fn(struct h
> struct signal_struct *sig =
> container_of(timer, struct signal_struct, real_timer);
>
> + trace_mark(kernel_timer_itimer_expired, "pid %d", sig->tsk->pid);
> +
> send_group_sig_info(SIGALRM, SEND_SIG_PRIV, sig->tsk);
>
> return HRTIMER_NORESTART;
> @@ -157,6 +159,15 @@ int do_setitimer(int which, struct itime
> !timeval_valid(>it_interval))
> return -EINVAL;
>
> + trace_mark(kernel_timer_itimer_set,
> + "which %d interval_sec %ld interval_usec %ld "
> + "value_sec %ld value_usec %ld",
> + which,
> + value->it_interval.tv_sec,
> + value->it_interval.tv_usec,
> + value->it_value.tv_sec,
> + value->it_value.tv_usec);
> +
> switch (which) {
> case ITIMER_REAL:
> again:
> Index: linux-2.6-lttng/kernel/kthread.c
> ===
> --- linux-2.6-lttng.orig/kernel/kthread.c 2007-11-13 09:25:27.0
> -0500
> +++ linux-2.6-lttng/kernel/kthread.c 2007-11-13 09:49:33.0 -0500
> @@ -195,6 +195,8 @@ int kthread_stop(struct task_struct *k)
> /* It could exit after stop_info.k set, but before wake_up_process. */
> get_task_struct(k);
>
> + trace_mark(kernel_kthread_stop, "pid %d", k->pid);
> +
> /* Must init completion *before* thread sees kthread_stop_info.k */
> init_completion(_stop_info.done);
> smp_wmb();
> @@ -210,6 +212,8 @@ int kthread_stop(struct task_struct *k)
> ret = kthread_stop_info.err;
> mutex_unlock(_stop_lock);
>
> + trace_mark(kernel_kthread_stop_ret, "ret %d", ret);
> +
> return ret;
> }
> EXPORT_SYMBOL(kthread_stop);
> Index: linux-2.6-lttng/kernel/lockdep.c
> ===
> --- linux-2.6-lttng.orig/kernel/lockdep.c 2007-11-13 09:25:27.0
> -0500
> +++ linux-2.6-lttng/kernel/lockdep.c 2007-11-13 09:49:33.0 -0500
> @@ -2014,6 +2014,9 @@ void trace_hardirqs_on(void)
> struct task_struct *curr = current;
> unsigned long ip;
>
> + _trace_mark(locking_hardirqs_on, "ip #p%lu",
> + (unsigned long) __builtin_return_address(0));
> +
> if (unlikely(!debug_locks || current->lockdep_recursion))
>
Re: MIPS RT debug support
On Thu, 15 Nov 2007, john cooper wrote: > > It isn't an issue of getting a hook into the FUNCTION_PROLOGUE > (mcount() here) but rather of emulating the CALLER_ADDR[0123] > defs which map onto the gcc internal __builtin_return_address(). > Doing so using the affectionately dubbed "Three Stooges Algorithm" > called out in the MIPS ABI is both complex and nondeterministic. > > The entry FUNCTION_PROLOGUE hook provides a means to log the path > traveled thus far. __builtin_return_address() gives a way to > snapshot a stub of the stack invocation. Together they provide > somewhat complimentary but useful debug information. > > We could log the stack invocation progress in the latency > instrumentation itself by noting a new invocation in the > FUNCTION_PROLOGUE and unwind of the same in the currently > unused FUNCTION_EPILOGUE hook. So we're just shadowing the > actual runtime stack in effect with a data structure which > can be traversed far more easily. > IIRC, only CALLER_ADDR0 is actually used (I've found that the others are mostly unreliable). I thought that mips always has one register that holds the return address of the function. It's been several years since I've worked on mips (I'd love to do it again, if someone sends me a box!, hint hint). So the __builtin_return_address(0) should simply return that register. Now I'm being a bit lazy, and I'm not pulling out my MIPS books, so I could be completely wrong on this. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: x86_64: Make sparsemem/vmemmap the default memory model
On Thu, 15 Nov 2007, Andrew Morton wrote: > Unfortunately some loon has gone and merged the i386 and x86_64 Kconfig > files. I was fixing that up but I worry what effects these Kconfig changes > might have on, for example, i386 NUMA setups. > > So I'll duck this version, sorry. Is there a tree that I can rediff the patch against? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/4] Add ARCH_SUPPORTS_OPROFILE
* Andrew Morton ([EMAIL PROTECTED]) wrote: > On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> > wrote: > > > arch/x86/Kconfig.i386 |1 + > > arch/x86/Kconfig.x86_64|1 + > > these no longer exist. Ok, should I prepare a fix or is it duplicated work ? -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 01/28] cpu alloc: The allocator
On Thu, 15 Nov 2007, David Miller wrote: > Well, the first version of the patch set, the one I tested, did > require a lot of BSS space. And that's the one they are writing > about. I am running the same version that you also ran. The problem is that you did not configure the stuff properly for your box and I did not include a configuration for sparc64 since I did not know how it needed to be configured for sparc64. You ignored the patch for sparc64 that I provided to correct the problem. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: tg3: strange errors and non-working-ness
I have created bug 9391 on bugzilla.kernel.org containing pretty much everything. -- Jon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/4] Add ARCH_SUPPORTS_OPROFILE
On Thu, 15 Nov 2007 20:59:27 -0500 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > arch/x86/Kconfig.i386 |1 + > arch/x86/Kconfig.x86_64|1 + these no longer exist. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 2/4] Add ARCH_SUPPORTS_OPROFILE
Linus: On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Changelog: Actually, I know I gave this as the magic incantation, but now that I see it, I realize that I should have told you to just use config ARCH_SUPPORTS_KPROBES def_bool y instead, which is a bit denser. We seem to use both kinds of syntax for these things, but this is really what "def_bool" is there for... - Use ARCH_HAS_* instead of ARCH_SUPPORTS). - Use a select ARCH_HAS_* Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/alpha/Kconfig |1 + arch/arm/Kconfig |1 + arch/blackfin/Kconfig |1 + arch/ia64/Kconfig |1 + arch/m32r/Kconfig |1 + arch/mips/Kconfig |1 + arch/parisc/Kconfig|1 + arch/powerpc/Kconfig |1 + arch/ppc/Kconfig |1 + arch/s390/Kconfig |1 + arch/sh/Kconfig|1 + arch/sh64/Kconfig |1 + arch/sparc/Kconfig |1 + arch/sparc64/Kconfig |1 + arch/x86/Kconfig.i386 |1 + arch/x86/Kconfig.x86_64|1 + kernel/Kconfig.instrumentation |5 - 17 files changed, 20 insertions(+), 1 deletion(-) Index: linux-2.6-lttng/arch/alpha/Kconfig === --- linux-2.6-lttng.orig/arch/alpha/Kconfig 2007-11-14 17:03:05.0 -0500 +++ linux-2.6-lttng/arch/alpha/Kconfig 2007-11-14 17:04:59.0 -0500 @@ -5,6 +5,7 @@ config ALPHA bool default y + select ARCH_HAS_OPROFILE help The Alpha is a 64-bit general-purpose processor designed and marketed by the Digital Equipment Corporation of blessed memory, Index: linux-2.6-lttng/arch/arm/Kconfig === --- linux-2.6-lttng.orig/arch/arm/Kconfig 2007-11-14 17:03:05.0 -0500 +++ linux-2.6-lttng/arch/arm/Kconfig2007-11-14 17:05:08.0 -0500 @@ -10,6 +10,7 @@ config ARM default y select RTC_LIB select SYS_SUPPORTS_APM_EMULATION + select ARCH_HAS_OPROFILE help The ARM series is a line of low-power-consumption RISC chip designs licensed by ARM Ltd and targeted at embedded applications and Index: linux-2.6-lttng/arch/blackfin/Kconfig === --- linux-2.6-lttng.orig/arch/blackfin/Kconfig 2007-11-14 17:03:05.0 -0500 +++ linux-2.6-lttng/arch/blackfin/Kconfig 2007-11-14 17:10:25.0 -0500 @@ -24,6 +24,7 @@ config RWSEM_XCHGADD_ALGORITHM config BLACKFIN bool default y + select ARCH_HAS_OPROFILE config ZONE_DMA bool Index: linux-2.6-lttng/arch/ia64/Kconfig === --- linux-2.6-lttng.orig/arch/ia64/Kconfig 2007-11-14 17:03:05.0 -0500 +++ linux-2.6-lttng/arch/ia64/Kconfig 2007-11-14 17:12:54.0 -0500 @@ -15,6 +15,7 @@ config IA64 select ACPI if (!IA64_HP_SIM) select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI + select ARCH_HAS_OPROFILE default y help The Itanium Processor Family is Intel's 64-bit successor to Index: linux-2.6-lttng/arch/m32r/Kconfig === --- linux-2.6-lttng.orig/arch/m32r/Kconfig 2007-11-14 17:03:05.0 -0500 +++ linux-2.6-lttng/arch/m32r/Kconfig 2007-11-14 17:10:49.0 -0500 @@ -8,6 +8,7 @@ mainmenu "Linux/M32R Kernel Configuratio config M32R bool default y + select ARCH_HAS_OPROFILE config SBUS bool Index: linux-2.6-lttng/arch/mips/Kconfig === --- linux-2.6-lttng.orig/arch/mips/Kconfig 2007-11-14 17:03:05.0 -0500 +++ linux-2.6-lttng/arch/mips/Kconfig 2007-11-14 17:06:22.0 -0500 @@ -1,6 +1,7 @@ config MIPS bool default y + select ARCH_HAS_OPROFILE # Horrible source of confusion. Die, die,
[patch 3/4] Add ARCH_SUPPORTS_KPROBES
Linus: On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Changelog: Actually, I know I gave this as the magic incantation, but now that I see it, I realize that I should have told you to just use config KPROBES_SUPPORT def_bool y instead, which is a bit denser. We seem to use both kinds of syntax for these things, but this is really what "def_bool" is there for... - Use ARCH_HAS_KPROBES - Use a select Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/avr32/Kconfig |1 + arch/ia64/Kconfig |1 + arch/powerpc/Kconfig |1 + arch/ppc/Kconfig |1 + arch/s390/Kconfig |1 + arch/sparc64/Kconfig |1 + arch/x86/Kconfig.i386 |1 + arch/x86/Kconfig.x86_64|1 + kernel/Kconfig.instrumentation |5 - 9 files changed, 12 insertions(+), 1 deletion(-) Index: linux-2.6-lttng/arch/avr32/Kconfig === --- linux-2.6-lttng.orig/arch/avr32/Kconfig 2007-11-14 17:03:05.0 -0500 +++ linux-2.6-lttng/arch/avr32/Kconfig 2007-11-14 17:11:33.0 -0500 @@ -11,6 +11,7 @@ config AVR32 # With EMBEDDED=n, we get lots of stuff automatically selected # that we usually don't need on AVR32. select EMBEDDED + select ARCH_HAS_KPROBES help AVR32 is a high-performance 32-bit RISC microprocessor core, designed for cost-sensitive embedded applications, with particular Index: linux-2.6-lttng/arch/ia64/Kconfig === --- linux-2.6-lttng.orig/arch/ia64/Kconfig 2007-11-14 17:05:38.0 -0500 +++ linux-2.6-lttng/arch/ia64/Kconfig 2007-11-14 17:11:45.0 -0500 @@ -16,6 +16,7 @@ config IA64 select PM if (!IA64_HP_SIM) select ARCH_SUPPORTS_MSI select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES default y help The Itanium Processor Family is Intel's 64-bit successor to Index: linux-2.6-lttng/arch/powerpc/Kconfig === --- linux-2.6-lttng.orig/arch/powerpc/Kconfig 2007-11-14 17:07:13.0 -0500 +++ linux-2.6-lttng/arch/powerpc/Kconfig2007-11-14 17:11:59.0 -0500 @@ -80,6 +80,7 @@ config PPC bool default y select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES config EARLY_PRINTK bool Index: linux-2.6-lttng/arch/ppc/Kconfig === --- linux-2.6-lttng.orig/arch/ppc/Kconfig 2007-11-14 17:07:55.0 -0500 +++ linux-2.6-lttng/arch/ppc/Kconfig2007-11-14 17:12:08.0 -0500 @@ -43,6 +43,7 @@ config PPC bool default y select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES config PPC32 bool Index: linux-2.6-lttng/arch/s390/Kconfig === --- linux-2.6-lttng.orig/arch/s390/Kconfig 2007-11-14 17:08:15.0 -0500 +++ linux-2.6-lttng/arch/s390/Kconfig 2007-11-14 17:12:19.0 -0500 @@ -52,6 +52,7 @@ mainmenu "Linux Kernel Configuration" config S390 def_bool y select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES source "init/Kconfig" Index: linux-2.6-lttng/arch/sparc64/Kconfig === --- linux-2.6-lttng.orig/arch/sparc64/Kconfig 2007-11-14 17:09:07.0 -0500 +++ linux-2.6-lttng/arch/sparc64/Kconfig2007-11-14 17:12:27.0 -0500 @@ -9,6 +9,7 @@ config SPARC bool default y select ARCH_HAS_OPROFILE + select ARCH_HAS_KPROBES config SPARC64 bool Index: linux-2.6-lttng/arch/x86/Kconfig.i386 === --- linux-2.6-lttng.orig/arch/x86/Kconfig.i386 2007-11-14 17:09:16.0 -0500 +++ linux-2.6-lttng/arch/x86/Kconfig.i386 2007-11-14 17:12:34.0 -0500 @@ -9,6 +9,7 @@ config X86_32 bool default y select
[patch 1/4] Create arch/Kconfig
Puts the content of arch/Kconfig in the "General setup" menu. Linus: > Should it come with a re-duplication of it's content into each > architecture, which was the case previously ? The oprofile and kprobes > menu entries were litteraly cut and pasted from one architecture to > another. Should we put its content in init/Kconfig then ? I don't think it's a good idea to go back to making it per-architecture, although that extensive "depends on " might indicate that there certainly is room for cleanup there. And I don't think it's wrong keeping it in kernel/Kconfig.xyz per se, I just think it's wrong to (a) lump the code together when it really doesn't necessarily need to and (b) show it to users as some kind of choice that is tied together (whether it then has common code or not). On the per-architecture side, I do think it would be better to *not* have internal architecture knowledge in a generic file, and as such a line like depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 really shouldn't exist in a file like kernel/Kconfig.instrumentation. It would be much better to do depends on ARCH_SUPPORTS_KPROBES in that generic file, and then architectures that do support it would just have a bool ARCH_SUPPORTS_KPROBES default y in *their* architecture files. That would seem to be much more logical, and is readable both for arch maintainers *and* for people who have no clue - and don't care - about which architecture is supposed to support which interface... Sam Ravnborg: Stuff it into a new file: arch/Kconfig We can then extend this file to include all the 'trailing' Kconfig things that are anyway equal for all ARCHs. But it should be kept clean - so if we introduce such a file then we should use ARCH_HAS_whatever in the arch specific Kconfig files to enable stuff that is not shared. [...] The above suggestion is actually not exactly the best way to do it... First the naming.. A quick grep shows following usage today (in Kconfig files) ARCH_HAS51 ARCH_SUPPORTS 4 HAVE_ARCH 7 ARCH_HAS is the clear winner. In the common Kconfig file do: config FOO depends on ARCH_HAS_FOO bool "bla bla" config ARCH_HAS_FOO def_bool n In the arch specific Kconfig file in a suitable place do: config SUITABLE_OPTION select ARCH_HAS_FOO The naming of ARCH_HAS_ is fixed and shall be: ARCH_HAS_ Only a single line added pr. architecture. And we will end up with a (maybe even commented) list of trivial selects. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig |3 +++ init/Kconfig |2 ++ 2 files changed, 5 insertions(+) Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-02 13:20:51.0 -0400 +++ linux-2.6-lttng/init/Kconfig2007-11-02 13:20:52.0 -0400 @@ -644,6 +644,8 @@ config SLOB endchoice +source "arch/Kconfig" + endmenu# General setup config RT_MUTEXES Index: linux-2.6-lttng/arch/Kconfig === --- /dev/null 1970-01-01 00:00:00.0 + +++ linux-2.6-lttng/arch/Kconfig2007-11-02 13:20:52.0 -0400 @@ -0,0 +1,3 @@ +# +# General architecture dependent options +# -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 4/4] Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig
Move the instrumentation Kconfig to arch/Kconfig for architecture dependent options - oprofile - kprobes and init/Kconfig for architecture independent options - profiling - markers Remove the "Instrumentation Support" menu. Everything moves to "General setup". Delete the kernel/Kconfig.instrumentation file. Signed-off-by: Mathieu Desnoyers <[EMAIL PROTECTED]> CC: Linus Torvalds <[EMAIL PROTECTED]> CC: Sam Ravnborg <[EMAIL PROTECTED]> --- arch/Kconfig | 28 arch/alpha/Kconfig |2 - arch/arm/Kconfig |2 - arch/blackfin/Kconfig |2 - arch/cris/Kconfig |2 - arch/frv/Kconfig |2 - arch/h8300/Kconfig |2 - arch/ia64/Kconfig |2 - arch/m32r/Kconfig |2 - arch/m68k/Kconfig |2 - arch/m68knommu/Kconfig |2 - arch/mips/Kconfig |2 - arch/parisc/Kconfig|2 - arch/powerpc/Kconfig |2 - arch/ppc/Kconfig |2 - arch/s390/Kconfig |2 - arch/sh/Kconfig|2 - arch/sh64/Kconfig |2 - arch/sparc/Kconfig |2 - arch/sparc64/Kconfig |2 - arch/um/Kconfig|2 - arch/v850/Kconfig |2 - arch/x86/Kconfig.i386 |2 - arch/x86/Kconfig.x86_64|2 - arch/xtensa/Kconfig|2 - init/Kconfig | 12 kernel/Kconfig.instrumentation | 55 - 27 files changed, 40 insertions(+), 103 deletions(-) Index: linux-2.6-lttng/arch/Kconfig === --- linux-2.6-lttng.orig/arch/Kconfig 2007-11-14 17:03:04.0 -0500 +++ linux-2.6-lttng/arch/Kconfig2007-11-14 17:12:57.0 -0500 @@ -1,3 +1,31 @@ # # General architecture dependent options # + +config OPROFILE + tristate "OProfile system profiling (EXPERIMENTAL)" + depends on PROFILING + depends on ARCH_HAS_OPROFILE + help + OProfile is a profiling system capable of profiling the + whole system, include the kernel, kernel modules, libraries, + and applications. + + If unsure, say N. + +config ARCH_HAS_OPROFILE + def_bool n + +config KPROBES + bool "Kprobes" + depends on KALLSYMS && MODULES + depends on ARCH_HAS_KPROBES + help + Kprobes allows you to trap at almost any kernel address and + execute a callback function. register_kprobe() establishes + a probepoint and specifies the callback. Kprobes is useful + for kernel debugging, non-intrusive instrumentation and testing. + If in doubt, say "N". + +config ARCH_HAS_KPROBES + def_bool n Index: linux-2.6-lttng/init/Kconfig === --- linux-2.6-lttng.orig/init/Kconfig 2007-11-14 17:03:04.0 -0500 +++ linux-2.6-lttng/init/Kconfig2007-11-14 17:12:57.0 -0500 @@ -644,6 +644,18 @@ config SLOB endchoice +config PROFILING + bool "Profiling support (EXPERIMENTAL)" + help + Say Y here to enable the extended profiling support mechanisms used + by profilers such as OProfile. + +config MARKERS + bool "Activate markers" + help + Place an empty function call at each marker site. Can be + dynamically changed for a probe function. + source "arch/Kconfig" endmenu# General setup Index: linux-2.6-lttng/kernel/Kconfig.instrumentation === --- linux-2.6-lttng.orig/kernel/Kconfig.instrumentation 2007-11-14 17:12:56.0 -0500 +++ /dev/null 1970-01-01 00:00:00.0 + @@ -1,55 +0,0 @@ -menuconfig INSTRUMENTATION - bool "Instrumentation Support" - default y - ---help--- - Say Y here to get to see options related to performance measurement, - system-wide debugging, and testing. This option alone does not add any - kernel code. - - If you say N, all options in this submenu will be skipped and - disabled. If you're trying to debug the kernel itself, go see the - Kernel Hacking menu. - -if INSTRUMENTATION - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - depends on ARCH_HAS_OPROFILE - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -config
[patch 0/4] Updated instrumentation menu patches
Hi Andrew, Here are the patches updated following Sam Ravnborg's comments. Mathieu -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MIPS RT debug support
Steven Rostedt wrote: On Thu, 15 Nov 2007, Tim Bird wrote: john cooper wrote: The more daunting problem stems from limitations in the MIPS ABI which makes the latency trace support problematic. Rather than rehash the issue: http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html Until we have a usable instrumentation solution in place, characterization, debug, and support of PREEMPT_RT for MIPS is going to be a challenge. Agreed. I have been using KFT (Kernel Function Trace) on MIPS, and it has decent support for function traceback reporting, but it's not currently integrated with latency-trace at all. We should discuss if this could possibly be used to debug RT-preempt. It is much heavier weight than the mcount stuff, but uses similar (but not identical) gcc profiling instrumentation. I'm not sure if the two can be turned on together, or how hard it would be to move latency-trace onto -finstrument_functions. I'm not familiar with the KFT but I'm sure it would be easy to port latency_trace to it. Really, all the mcount does is make a wrapper to pass to the trace calls. It isn't an issue of getting a hook into the FUNCTION_PROLOGUE (mcount() here) but rather of emulating the CALLER_ADDR[0123] defs which map onto the gcc internal __builtin_return_address(). Doing so using the affectionately dubbed "Three Stooges Algorithm" called out in the MIPS ABI is both complex and nondeterministic. The entry FUNCTION_PROLOGUE hook provides a means to log the path traveled thus far. __builtin_return_address() gives a way to snapshot a stub of the stack invocation. Together they provide somewhat complimentary but useful debug information. We could log the stack invocation progress in the latency instrumentation itself by noting a new invocation in the FUNCTION_PROLOGUE and unwind of the same in the currently unused FUNCTION_EPILOGUE hook. So we're just shadowing the actual runtime stack in effect with a data structure which can be traversed far more easily. -john -- [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: EIP is at device_shutdown+0x32/0x60
On Fri, Nov 16, 2007 at 10:13:42AM +0900, Yasunori Goto wrote:
> > >
> > > Care to try this:
> > > + system_kset = kset_create_and_register("system", NULL,
> > > + _kset->kobj,
> > > NULL);
> > >
> > > We should not join the kset, only use it as a parent.
> >
> > Yes, that fixes the problem for me!
> >
> > Can anyone else verify this?
>
> I confirmed it fixed the problem. :-)
Thanks for testing, the next -mm should have this fix.
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets
Hi,
On Thu, 15 Nov 2007, Sam Ravnborg wrote:
> You suggest just to check ARCH value and not apply your patch. This was
> not my initial understanding as was hopefully obvious from my reply.
This patch only adds some extra features.
> If user did NOT specify ARCH we should use the kernel configuration - which
> your solution fail to do.
To make this easy I attached the patch which reverts the problematic
changes and then you only need this simple change to force the 64BIT value
for ARCH={i386,x86_64}, otherwise it's set by the user:
bye, Roman
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Makefile |3 ++-
arch/x86/Kconfig |4 ++--
2 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -165,7 +165,8 @@ export srctree objtree VPATH TOPDIR
# then ARCH is assigned, getting whatever value it gets normally, and
# SUBARCH is subsequently ignored.
-SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
+SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+ -e s/sun4u/sparc64/ \
-e s/arm.*/arm/ -e s/sa110/arm/ \
-e s/s390x/s390/ -e s/parisc64/parisc/ \
-e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
Index: linux-2.6/arch/x86/Kconfig
===
--- linux-2.6.orig/arch/x86/Kconfig
+++ linux-2.6/arch/x86/Kconfig
@@ -3,8 +3,8 @@ mainmenu "Linux Kernel Configuration for
# Select 32 or 64 bit
config 64BIT
- bool "64-bit kernel"
- default n
+ bool "64-bit kernel" if ARCH="x86"
+ default ARCH="x86_64"
help
Say yes to build a 64-bit kernel - formerly known as x86_64
Say no to build a 32-bit kernel - formerly known as i386Revert
9c900a9c9d9351e55ab6a84e12e3a52c474c7c8b
0f855aa64b3f63d35a891510cf7db932a435c116
2a113281f5cd2febbab21a93c8943f8d3eece4d3
and K64BIT parts of
daa93fab824f2b8c35bd11670c7fab2f32b2de5f
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
Makefile|4 -
README |2
scripts/kconfig/conf.c |1
scripts/kconfig/confdata.c | 146
scripts/kconfig/lkc_proto.h |1
5 files changed, 56 insertions(+), 98 deletions(-)
Index: linux-2.6/Makefile
===
--- linux-2.6.orig/Makefile
+++ linux-2.6/Makefile
@@ -200,11 +200,9 @@ SRCARCH:= $(ARCH)
# Additional ARCH settings for x86
ifeq ($(ARCH),i386)
SRCARCH := x86
-K64BIT := n
endif
ifeq ($(ARCH),x86_64)
SRCARCH := x86
-K64BIT := y
endif
KCONFIG_CONFIG ?= .config
@@ -341,7 +339,7 @@ KERNELRELEASE = $(shell cat include/conf
KERNELVERSION = $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
-export ARCH SRCARCH K64BIT CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD
CC
+export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC
export CPP AR NM STRIP OBJCOPY OBJDUMP MAKE AWK GENKSYMS PERL UTS_MACHINE
export HOSTCXX HOSTCXXFLAGS LDFLAGS_MODULE CHECK CHECKFLAGS
Index: linux-2.6/README
===
--- linux-2.6.orig/README
+++ linux-2.6/README
@@ -194,8 +194,6 @@ CONFIGURING the kernel:
"make *config" checks for a file named "all{yes/mod/no/random}.config"
for symbol values that are to be forced. If this file is not found,
it checks for a file named "all.config" to contain forced values.
- Finally it checks the environment variable K64BIT and if found, sets
- the config symbol "64BIT" to the value of the K64BIT variable.
NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
Index: linux-2.6/scripts/kconfig/conf.c
===
--- linux-2.6.orig/scripts/kconfig/conf.c
+++ linux-2.6/scripts/kconfig/conf.c
@@ -591,7 +591,6 @@ int main(int ac, char **av)
conf_read_simple(name, S_DEF_USER);
else if (!stat("all.config", ))
conf_read_simple("all.config", S_DEF_USER);
- conf_set_env_sym("K64BIT", "64BIT", S_DEF_USER);
break;
default:
break;
Index: linux-2.6/scripts/kconfig/confdata.c
===
--- linux-2.6.orig/scripts/kconfig/confdata.c
+++ linux-2.6/scripts/kconfig/confdata.c
@@ -83,95 +83,6 @@ char *conf_get_default_confname(void)
return name;
}
-static int conf_set_sym_val(struct symbol *sym, int def, int def_flags, char
*p)
-{
- char *p2;
-
-
Re: 2.6.24-rc2-mm1 -- strange apparent network failures
unsubscribe linux-kernel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1 -- strange apparent network failures
On Thu, 15 Nov 2007 21:01:32 -0400 Kevin Winchester <[EMAIL PROTECTED]> wrote: > On November 15, 2007 08:44:41 pm Andrew Morton wrote: > > On Thu, 15 Nov 2007 20:28:29 -0400 > > > > Kevin Winchester <[EMAIL PROTECTED]> wrote: > > > On November 15, 2007 06:02:09 am Andy Whitcroft wrote: > > > > I see this as well - the computer boots fine but no network. The only > > > clues in the dmesg are: > > > > > > [ 294.097876] warning: process `dhclient' gets w/ old libcap > > > [ 294.097893] warning: process `dhclient' sets w/ old libcap > > > > > > So I'll try backing up the patch series to before: > > > > > > add-64-bit-capability-support-to-the-kernel.patch > > > > That's the winner. The changelog indicates that the patch is meant to keep > compatibility with older userspace, so I guess it didn't quite keep as much > compatibility as it wanted. OK, thanks for working that out - I'll temporarily drop that patch until we get it sorted. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MIPS RT debug support
On Thu, 15 Nov 2007, Tim Bird wrote: > john cooper wrote: > > The more daunting problem stems from limitations in the MIPS > > ABI which makes the latency trace support problematic. > > Rather than rehash the issue: > > > > http://lists.linuxcoding.com/kernel/2005-q4/msg10163.html > > > > Until we have a usable instrumentation solution in place, > > characterization, debug, and support of PREEMPT_RT for MIPS > > is going to be a challenge. > > Agreed. I have been using KFT (Kernel Function Trace) > on MIPS, and it has decent support for function traceback > reporting, but it's not currently integrated with latency-trace > at all. We should discuss if this could possibly be > used to debug RT-preempt. It is much heavier weight than > the mcount stuff, but uses similar (but not identical) > gcc profiling instrumentation. I'm not sure if the > two can be turned on together, or how hard it would > be to move latency-trace onto -finstrument_functions. I'm not familiar with the KFT but I'm sure it would be easy to port latency_trace to it. Really, all the mcount does is make a wrapper to pass to the trace calls. Here's the code for mcount in arch/x86/kernel/entry_64.S: ENTRY(mcount) cmpl $0, mcount_enabled jz out push %rbp mov %rsp,%rbp push %r11 push %r10 push %r9 push %r8 push %rdi push %rsi push %rdx push %rcx push %rax mov 0x0(%rbp),%rax mov 0x8(%rbp),%rdi mov 0x8(%rax),%rsi call __trace pop %rax pop %rcx pop %rdx pop %rsi pop %rdi pop %r8 pop %r9 pop %r10 pop %r11 pop %rbp out: ret Which simply passes to __trace the rip that jumped here, and (if possible) the rip of that caller. The parent rip is not necessary. > > But it's probably worth researching a little. We'll > need something to give insight into the problem paths. If the KFT could do the above, it should be trivial to adapt. Hmm, if someone is willing to send me a free mips box, I may do it myself ;-) -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1 -- strange apparent network failures
On November 15, 2007 08:44:41 pm Andrew Morton wrote: > On Thu, 15 Nov 2007 20:28:29 -0400 > > Kevin Winchester <[EMAIL PROTECTED]> wrote: > > On November 15, 2007 06:02:09 am Andy Whitcroft wrote: > > I see this as well - the computer boots fine but no network. The only > > clues in the dmesg are: > > > > [ 294.097876] warning: process `dhclient' gets w/ old libcap > > [ 294.097893] warning: process `dhclient' sets w/ old libcap > > > > So I'll try backing up the patch series to before: > > > > add-64-bit-capability-support-to-the-kernel.patch > That's the winner. The changelog indicates that the patch is meant to keep compatibility with older userspace, so I guess it didn't quite keep as much compatibility as it wanted. I have no idea what I'm doing, but I'll take a look at the patch anyway... -- Kevin Winchester - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.24-rc2-mm1] memory hotplug x86_64 fix [3/3] fix section mismatch in init_memory_mapping
On Thu, 15 Nov 2007 19:36:39 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> Changes __meminit to __init_refok.
> ==
> WARNING: vmlinux.o(.text+0x1d07c): Section mismatch: reference to
> .init.text:find_e820_area (between 'init_memory_mapping' and
> 'arch_add_memory')
> ==
>
> Changelog:
> * changes __init_refok from find_early_table_space() to
>init_memory_mapping().
>
> Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
>
> arch/x86/mm/init_64.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c
> ===
> --- linux-2.6.24-rc2-mm1.orig/arch/x86/mm/init_64.c
> +++ linux-2.6.24-rc2-mm1/arch/x86/mm/init_64.c
> @@ -347,7 +347,7 @@ static void __init find_early_table_spac
> /* Setup the direct mapping of the physical memory at PAGE_OFFSET.
> This runs before bootmem is initialized and gets pages directly from the
> physical memory. To access them they are temporarily mapped. */
> -void __meminit init_memory_mapping(unsigned long start, unsigned long end)
> +void __init_refok init_memory_mapping(unsigned long start, unsigned long end)
> {
> unsigned long next;
>
again, I _think_ this fixes a bug in mainline. Can you check that please?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: EIP is at device_shutdown+0x32/0x60
> >
> > Care to try this:
> > + system_kset = kset_create_and_register("system", NULL,
> > + _kset->kobj, NULL);
> >
> > We should not join the kset, only use it as a parent.
>
> Yes, that fixes the problem for me!
>
> Can anyone else verify this?
I confirmed it fixed the problem. :-)
Thanks.
--
Yasunori Goto
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
On Nov 16, 2007 8:49 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > On Fri, Nov 16, 2007 at 08:39:12AM +0800, Dave Young wrote: > > On Nov 16, 2007 3:23 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > On Wed, Nov 14, 2007 at 10:19:48AM -0800, Greg KH wrote: > > > > On Wed, Nov 14, 2007 at 06:02:07PM +0100, Jiri Kosina wrote: > > > > > On Wed, 14 Nov 2007, Jiri Kosina wrote: > > > > > > > > > > > > I'd suspect the driver tree. I think I'll need to do a quick -mm2 > > > > > > > without that tree present. > > > > > > I am just verifying whether reverting kset changes fixes this, will > > > > > > let > > > > > > you know soon. > > > > > > > > > > OK, so I reverted > > > > > gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which > > > > > made me > > > > > also revert gregkh-driver-kobject-remove-subsystem_register-functions > > > > > and > > > > > gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both > > > > > the > > > > > error message from lockdep and more importantly the spinlock lockup > > > > > have > > > > > gone, and the system with these patches reverted boots for me fine. > > > > > > > > > > Well not that fine, I still see (which is the same backtrace that > > > > > caused > > > > > the lockup with plain -rc2-mm1, but doesn't make the machine hang): > > > > > > > > > > floppy0: Floppy io-port 0x03f2 in use > > > > > WARNING: at lib/kref.c:33 kref_get() > > > > > > > > > > Call Trace: > > > > > [] kobject_add+0x9b/0x197 > > > > > [] kref_get+0x2f/0x36 > > > > > [] kobject_get+0x12/0x17 > > > > > [] kobject_add+0xad/0x197 > > > > > [] register_disk+0x48/0x205 > > > > > [] add_disk+0x34/0x3d > > > > > [] rd_init+0x172/0x1e1 > > > > > [] kernel_init+0x175/0x2e6 > > > > > [] trace_hardirqs_on+0x115/0x139 > > > > > [] trace_hardirqs_on_thunk+0x35/0x3a > > > > > [] trace_hardirqs_on+0x115/0x139 > > > > > [] child_rip+0xa/0x12 > > > > > [] restore_args+0x0/0x30 > > > > > [] kernel_init+0x0/0x2e6 > > > > > [] child_rip+0x0/0x12 > > > > > > > > someone is trying to call kref_get on a kobject that has not been > > > > initialized yet, which could be the reason the newer patches break > > > > something, as the pointers are not set up properly with a call to > > > > kobject_init() first. > > > > > > > > But, alloc_disk() should have been called on this gendisk for it to work > > > > properly at all, unless something is trashing that structure? > > > > > > > > I'm way confused... > > > > > > This patch, as found by Dave Young, should fix the issue: > > > > > > I'll roll it into my larger patchset so that Andrew will get it > > > automatically next release, but here it is for people to use now. > > > > > > thanks, > > > > > > greg k-h > > > > > > -- > > > > > > From: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > > Subject: fix bug with adding new block devices in -mm > > > > > > need to set the kset before initializing the kobject. > > > > > > > > > --- > > > block/genhd.c |2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > --- a/block/genhd.c > > > +++ b/block/genhd.c > > > @@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino > > > } > > > } > > > disk->minors = minors; > > > - kobject_init(>kobj); > > > disk->kobj.kset = block_kset; > > > disk->kobj.ktype = _block; > > > + kobject_init(>kobj); > > > rand_initialize_disk(disk); > > > INIT_WORK(>async_notify, > > > media_change_notify_thread); > > > > > > - > > Hi, > > Could you please add signed-off by me? > > > > Signed-off-by: Dave Young <[EMAIL PROTECTED]> > > Sure, but I've modified the original patch to not include this bug in > the first place, so there's really not much to sign off on there, sorry. > > I will add your name as helping out with it, if that's ok. > Ok, thanks. Regards dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1
On Fri, Nov 16, 2007 at 08:39:12AM +0800, Dave Young wrote: > On Nov 16, 2007 3:23 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Wed, Nov 14, 2007 at 10:19:48AM -0800, Greg KH wrote: > > > On Wed, Nov 14, 2007 at 06:02:07PM +0100, Jiri Kosina wrote: > > > > On Wed, 14 Nov 2007, Jiri Kosina wrote: > > > > > > > > > > I'd suspect the driver tree. I think I'll need to do a quick -mm2 > > > > > > without that tree present. > > > > > I am just verifying whether reverting kset changes fixes this, will > > > > > let > > > > > you know soon. > > > > > > > > OK, so I reverted > > > > gregkh-driver-kset-convert-block_subsys-to-use-kset_create (which made > > > > me > > > > also revert gregkh-driver-kobject-remove-subsystem_register-functions > > > > and > > > > gregkh-driver-kset-remove-decl_subsys-macro so that we compile). Both > > > > the > > > > error message from lockdep and more importantly the spinlock lockup have > > > > gone, and the system with these patches reverted boots for me fine. > > > > > > > > Well not that fine, I still see (which is the same backtrace that caused > > > > the lockup with plain -rc2-mm1, but doesn't make the machine hang): > > > > > > > > floppy0: Floppy io-port 0x03f2 in use > > > > WARNING: at lib/kref.c:33 kref_get() > > > > > > > > Call Trace: > > > > [] kobject_add+0x9b/0x197 > > > > [] kref_get+0x2f/0x36 > > > > [] kobject_get+0x12/0x17 > > > > [] kobject_add+0xad/0x197 > > > > [] register_disk+0x48/0x205 > > > > [] add_disk+0x34/0x3d > > > > [] rd_init+0x172/0x1e1 > > > > [] kernel_init+0x175/0x2e6 > > > > [] trace_hardirqs_on+0x115/0x139 > > > > [] trace_hardirqs_on_thunk+0x35/0x3a > > > > [] trace_hardirqs_on+0x115/0x139 > > > > [] child_rip+0xa/0x12 > > > > [] restore_args+0x0/0x30 > > > > [] kernel_init+0x0/0x2e6 > > > > [] child_rip+0x0/0x12 > > > > > > someone is trying to call kref_get on a kobject that has not been > > > initialized yet, which could be the reason the newer patches break > > > something, as the pointers are not set up properly with a call to > > > kobject_init() first. > > > > > > But, alloc_disk() should have been called on this gendisk for it to work > > > properly at all, unless something is trashing that structure? > > > > > > I'm way confused... > > > > This patch, as found by Dave Young, should fix the issue: > > > > I'll roll it into my larger patchset so that Andrew will get it > > automatically next release, but here it is for people to use now. > > > > thanks, > > > > greg k-h > > > > -- > > > > From: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > Subject: fix bug with adding new block devices in -mm > > > > need to set the kset before initializing the kobject. > > > > > > --- > > block/genhd.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > --- a/block/genhd.c > > +++ b/block/genhd.c > > @@ -718,9 +718,9 @@ struct gendisk *alloc_disk_node(int mino > > } > > } > > disk->minors = minors; > > - kobject_init(>kobj); > > disk->kobj.kset = block_kset; > > disk->kobj.ktype = _block; > > + kobject_init(>kobj); > > rand_initialize_disk(disk); > > INIT_WORK(>async_notify, > > media_change_notify_thread); > > > > - > Hi, > Could you please add signed-off by me? > > Signed-off-by: Dave Young <[EMAIL PROTECTED]> Sure, but I've modified the original patch to not include this bug in the first place, so there's really not much to sign off on there, sorry. I will add your name as helping out with it, if that's ok. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][2.6.24-rc2-mm1] memory hotplug x86_64 fix [2/3] fix section mismatch in vmammap_allock_block
On Thu, 15 Nov 2007 19:35:44 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Fixes section mismatch below.
>
> WARNING: vmlinux.o(.text+0x946b5): Section mismatch: reference to .init.text:'
> __alloc_bootmem_node (between 'vmemmap_alloc_block' and
> 'vmemmap_pgd_populate')
>
> Changelog
> - changed bootmem alloc wrapper function's name to be
> __earlyonly_bootmem_alloc().
>
> Signed-off-by: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
>
>
> mm/sparse-vmemmap.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.24-rc2-mm1/mm/sparse-vmemmap.c
> ===
> --- linux-2.6.24-rc2-mm1.orig/mm/sparse-vmemmap.c
> +++ linux-2.6.24-rc2-mm1/mm/sparse-vmemmap.c
> @@ -34,6 +34,16 @@
> * or to back the page tables that are used to create the mapping.
> * Uses the main allocators if they are available, else bootmem.
> */
> +
> +static void * __init_refok __earlyonly_bootmem_alloc(int node,
> + unsigned long size,
> + unsigned long align,
> + unsigned long goal)
> +{
> + return __alloc_bootmem_node(NODE_DATA(node), size, align, goal);
> +}
> +
> +
> void * __meminit vmemmap_alloc_block(unsigned long size, int node)
> {
> /* If the main allocator is up use that, fallback to bootmem. */
> @@ -44,7 +54,7 @@ void * __meminit vmemmap_alloc_block(uns
> return page_address(page);
> return NULL;
> } else
> - return __alloc_bootmem_node(NODE_DATA(node), size, size,
> + return __earlyonly_bootmem_alloc(node, size, size,
> __pa(MAX_DMA_ADDRESS));
> }
>
AFACIT this is applicable to mainline?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Treat disk space like memory space
Stefan Monnier wrote: So I'd like to be able to say "these areas of my file-system hold data that you can discard whenever you need space". So I can freely fill up my disk with such irrelevant data, safe in the knowledge that if I ever need this disk space it'll be automatically reclaimed. James Cipar, Mark D. Corner, Emery D. Berger: TFS: A Transparent File System for Contributory Storage. "TFS provides background tasks with large amounts of unreliable storage-all of the currently available space-without impacting the performance of ordinary file access operations." http://www.usenix.org/event/fast07/tech/cipar.html http://prisms.cs.umass.edu/tcsm/ It's intended for P2P but I could imagine using it for caches. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mmap dirty limits on 32 bit kernels (Was: [BUG] New Kernel Bugs)
> So the _only_ explanation today for 12GB on a 32-bit machine is > (a) insanity > or > (b) being so lazy as to not bother to upgrade > and in either case, my personal reaction is "I'm *not* crazy, and yes, I'm > lazy too, and I can't give a rats *ss about those problems". 12GB-16GB worked well historically so its a regression. Above 16GB its all utterly mad. You forgot reason (c) though (c) 32bit is a tested approved certified etc environment - essentially conservativsm and paranoia, and its hard to explain to some of these people that the right answer really is less RAM or 64bit, especially as they may already know it but have a 12 month process to prove and certify a system configuration. > HIGHMEM was a mistake in the first place. It's one that we can live with, > but I refuse to support it more than it needs to be supported. And 12GB is > *way* past the end of what is worth supporting. Highmem to 4GB was sensible. Highmem to 8GB was pushing it. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc2-mm1 -- strange apparent network failures
On Thu, 15 Nov 2007 20:28:29 -0400 Kevin Winchester <[EMAIL PROTECTED]> wrote: > On November 15, 2007 06:02:09 am Andy Whitcroft wrote: > > When testing some of the later 2.6.24-rc2-mm1+hotfix combinations on three > > of our test systems one job from each batch (1/4) failed. In each case the > > machine appears to have booted normally all the way to a login: prompt. > > However in the failed boots the networking though apparently initialised > > completely and correctly (as far as I can tell from the console output), is > > reported as not responding to ssh connections. The network interface seems > > to have been initialised on the right port, and the ssh daemons started. > > > > Two of the machines are powerpc boxes, the other an older x86_64. > > One machine is 4/4 in testing, just one. Most of the other machines are > > still not able to compile this stack so do not contribute to our knowledge. > > > > Any ideas? > > > > I see this as well - the computer boots fine but no network. The only clues > in the dmesg are: > > [ 294.097876] warning: process `dhclient' gets w/ old libcap > [ 294.097893] warning: process `dhclient' sets w/ old libcap > > So I'll try backing up the patch series to before: > > add-64-bit-capability-support-to-the-kernel.patch Yes, that's a good one to suspect. What a peculiar error message. > or so, and see if that's the problem. If anyone has any other ideas, let me > know. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: broken suspend [Was: 2.6.24-rc2-mm1]
On Fri, Nov 16, 2007 at 12:59:41AM +0100, Jiri Slaby wrote: > On 11/14/2007 10:48 PM, Rafael J. Wysocki wrote: > > On Wednesday, 14 of November 2007, Jiri Slaby wrote: > >> On 11/14/2007 02:59 AM, Andrew Morton wrote: > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/ > >> Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64. > >> echo mem >/sys/power/state > >> causes shut down of disk(s) and blinking cursor on 1,1 position. > >> The last working was 2.6.23-rc8-mm2. I haven't tested > >> 2.6.23-mm1, since it didn't work for me. > > > > Does the current mainline work? > > Yes. > > The offending -mm patch is > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch > > 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when > the patch is applied. Thanks for tracking this down. Alan, any thoughts? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why preallocate pmd in x86 32-bit PAE?
William Lee Irwin III wrote: There may be bigger fish to fry in terms of per-process overhead, if you're trying to cut that down. The trouble with trying to address some of those is that there is mutual antagonism between compactness and expansibility in the process address space layout, so you'll end up instantiating a lot more than you want barring some sort of provision for a compact address space layout. Pagetable sharing is a far more powerful resource scalability method, though it also needs cooperation in user address space layout to reap its gains. There are other overheads, of course, though they're more typically per-something besides processes. I think Jeremy's question was due to trying to reduce the 32/64-bit differences. Performance-wise, it might add a small amount to user setup time (a typical 32-bit process will need all four, for the main binary, libraries, stack and kernel, respectively) but it is probably not significant (although I'd like to see numbers just in case). -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
