Andrew Morton wrote:
> On Tue, 27 Mar 2007 14:49:20 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> wrote:
>
>
>> The softlockup watchdog is currently a nuisance in a virtual machine,
>> since the whole system could have the CPU stolen from it for a long
>> period of time. While it would be un
* Ed Tomlinson <[EMAIL PROTECTED]> wrote:
> > SD 0.46 1-2 FPS
> > cfs v5 nice -19 219-233 FPS
> > cfs v5 nice 0 1000-1996
>cfs v5 nice -10 60-65 FPS
the problem is, the glxgears portion of this test is an _inverse_
testcase.
The reason? glxgears on true 3D hardware w
On Tue, 27 Mar 2007 14:49:20 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> The softlockup watchdog is currently a nuisance in a virtual machine,
> since the whole system could have the CPU stolen from it for a long
> period of time. While it would be unlikely for a guest domain to be
>
Paul Mackerras wrote:
> Srinivasa Ds writes:
>
>> +} else {\
>> +char dot_name[KSYM_NAME_LEN+1]; \
>> +dot_name[0] = '.'; \
>> +dot_name[1] =
On Thu, 15 Mar 2007 16:46:39 +0100 Gerd Hoffmann <[EMAIL PROTECTED]> wrote:
> The console subsystem already has an idea of a boot console, using the
> CON_BOOT flag. The implementation has some flaws though. The major
> problem is that presence of a boot console makes register_console()
> ignore
On Tue, 24 Apr 2007, Cestonaro, Thilo (external) wrote:
Hey,
is it right, that the NX Bit is not used under i386-Arch but under x86_64-Arch?
When yes, is there a special argument for it not to be used?
Ciao Thilo
I don't think so - some i386 cpus definitely have support for the NX bit.
Would
* Peter Williams <[EMAIL PROTECTED]> wrote:
> > The cases are fundamentally different in behavior, because in the
> > first case, X hardly consumes the time it would get in any scheme,
> > while in the second case X really is CPU bound and will happily
> > consume any CPU time it can get.
>
>
On Sun, Apr 22, 2007 at 11:12:13PM -0600, Eric W. Biederman wrote:
>
> Currently because vmlinux does not reflect that the kernel is relocatable
> we still have to support CONFIG_PHYSICAL_START. So this patch adds a small
> c program to do what we cannot do with a linker script, set the elf heade
Hey,
is it right, that the NX Bit is not used under i386-Arch but under x86_64-Arch?
When yes, is there a special argument for it not to be used?
Ciao Thilo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
Arjan van de Ven wrote:
Within reason, it's not the number of clients that X has that causes its
CPU bandwidth use to sky rocket and cause problems. It's more to to
with what type of clients they are. Most GUIs (even ones that are
constantly updating visual data (e.g. gkrellm -- I can open qu
Roland McGrath wrote:
>> I have to admit I still don't really understand all this. Is it
>> documented somewhere?
>>
>
> I have explained it in public more than once, but I don't know off hand
> anywhere that was helpfully recorded.
>
Thanks very much. I'd been poking about, but the clos
On Sun, 22 Apr 2007 19:00:46 -0700, "Eric Hopper"
<[EMAIL PROTECTED]> said:
> I know that this whole effort has been put in disarray by the
> prosecution of Hans Reiser, but I'm curious as to its status. Is
> Reiser4 going to be going into the Linus kernel anytime soon? Is there
> somewhere I shou
Christoph Hellwig writes:
> The first question is obviously, is this really something we want?
> spawning kernel thread on demand without reaping them properly seems
> quite dangerous.
What specifically has to be done to reap a kernel thread? Are you
concerned about the number of threads, or abo
On Mon, 23 Apr 2007, Christoph Lameter wrote:
> Obvious fix. It was broken by
>
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=f2a2a7108aa0039ba7a5fe7a0d2ecef2219a7584
> Dec 7. So its in 2.6.20 and later. Candiate for stable?
>
I agree it's obvious enough tha
Srinivasa Ds writes:
> + } else {\
> + char dot_name[KSYM_NAME_LEN+1]; \
> + dot_name[0] = '.'; \
> + dot_name[1] = '\0';
> Since we need to have some way to track them having an explicit data
> structure that the callers manage seems to make sense.
Oh sure, I wasn't arguing against that at all...
It might be handy to have a release() callback (optional) that gets
called after the kthread stops/exits, once we know t
On Mon, Apr 23, 2007 at 09:34:55PM -0700, Jeremy Fitzhardinge wrote:
>
> Could you give netfront an overall review as well? I know you're
> already pretty familiar with it, but if you could cast a fresh eye over
> it, that would be helpful.
Sure thing. I'll look over it soon.
Actually there is
On Tue, 24 Apr 2007 05:44:42 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
> On Mon, 23 Apr 2007, Andrew Morton wrote:
> > On Tue, 24 Apr 2007 05:10:04 + (GMT) William Heimbigner <[EMAIL
> > PROTECTED]> wrote:
> >
> >>> --- a/drivers/block/pktcdvd.c~packet-fix-error-handling
> >>
From: Alan Cox <[EMAIL PROTECTED]>
Date: Mon, 23 Apr 2007 14:58:40 +0100
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
Applied, thanks 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.
On Mon, 23 Apr 2007, David Rientjes wrote:
> oom_kill_task() calls __oom_kill_task() to OOM kill a selected task.
> When finding other threads that share an mm with that task, we need to
> kill those individual threads and not the same one.
Obvious fix. It was broken by
http://git.kernel.org/?p
On Mon, Apr 23, 2007 at 09:36:13PM -0700, David Rientjes wrote:
> oom_kill_task() calls __oom_kill_task() to OOM kill a selected task.
> When finding other threads that share an mm with that task, we need to
> kill those individual threads and not the same one.
ISTR shooting down something of this
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>> Further in general it doesn't make sense to grab a module reference
>> and call that sufficient because we would like to request that the
>> module exits.
>
> Which is, btw, I think a total misdesign of our module stuff, but heh, I
> remember t
On Mon, 23 Apr 2007, Andrew Morton wrote:
On Tue, 24 Apr 2007 05:10:04 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
--- a/drivers/block/pktcdvd.c~packet-fix-error-handling
+++ a/drivers/block/pktcdvd.c
@@ -777,7 +777,8 @@ static int pkt_generic_packet(struct pkt
rq
Handle MAP_FIXED in i386 hugetlb_get_unmapped_area(), just call
prepare_hugepage_range.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: William Irwin <[EMAIL PROTECTED]>
arch/i386/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/arch/i386/mm/
Handle MAP_FIXED in arch_get_unmapped_area on frv. Trivial case, just
return the address.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
arch/frv/mm/elf-fdpic.c |4
1 file changed, 4 insertions(+)
Index: linux-cell/arch/frv/mm/elf-fdpic.c
Handle MAP_FIXED in x86_64 arch_get_unmapped_area(), simple case, just
return the address as passed in
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
arch/x86_64/kernel/sys_x86_64.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/x86_64/kernel/sys_x86_64.c
Handle MAP_FIXED in hugetlb_get_unmapped_area on sparc64
by just using prepare_hugepage_range()
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: William Irwin <[EMAIL PROTECTED]>
arch/sparc64/mm/hugetlbpage.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/ar
Handle MAP_FIXED in parisc arch_get_unmapped_area(), just return the
address. We might want to also check for possible cache aliasing
issues now that we get called in that case (like ARM or MIPS),
leave a comment for the maintainers to pick up.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECT
Handle MAP_FIXED in ia64 arch_get_unmapped_area and
hugetlb_get_unmapped_area(), just call prepare_hugepage_range
in the later and is_hugepage_only_range() in the former.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: William Irwin <[EMAIL PROTECTED]>
arch/ia64/kernel/sys_ia
Generic hugetlb_get_unmapped_area() now handles MAP_FIXED by just
calling prepare_hugepage_range()
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: William Irwin <[EMAIL PROTECTED]>
fs/hugetlbfs/inode.c |6 ++
1 file changed, 6 insertions(+)
Index: linux-cell/fs/huget
Remove the hugetlbfs specific hacks in toplevel get_unmapped_area() now
that all archs and hugetlbfs itself do the right thing for both cases.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: William Irwin <[EMAIL PROTECTED]>
mm/mmap.c | 16
1 file changed,
ARM already had a case for MAP_FIXED in arch_get_unmapped_area() though
it was not called before. Fix the comment to reflect that it will now
be called.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
arch/arm/mm/mmap.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index:
generic arch_get_unmapped_area() now handles MAP_FIXED. Now that
all implementations have been fixed, change the toplevel
get_unmapped_area() to call into arch or drivers for the MAP_FIXED
case.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
mm/mmap.c | 25 +++--
Handle MAP_FIXED in powerpc's arch_get_unmapped_area() in all 3
implementations of it.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Acked-by: William Irwin <[EMAIL PROTECTED]>
arch/powerpc/mm/hugetlbpage.c | 21 +
1 file changed, 21 insertions(+)
Index: linux-
Handle MAP_FIXED in alpha's arch_get_unmapped_area(), simple case, just
return the address as passed in
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
arch/alpha/kernel/osf_sys.c |3 +++
1 file changed, 3 insertions(+)
Index: linux-cell/arch/alpha/kernel/osf_sys.c
===
This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
(Andrew, this is also candidate for 2.6.22 since I haven't had any real
objection, mostly sug
On Tue, 24 Apr 2007 05:10:04 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
> > --- a/drivers/block/pktcdvd.c~packet-fix-error-handling
> > +++ a/drivers/block/pktcdvd.c
> > @@ -777,7 +777,8 @@ static int pkt_generic_packet(struct pkt
> > rq->cmd_flags |= REQ_QUIET;
> >
> >
I tested this patch. It worked well.
So, I fixed its description.
Please apply.
--
The current panic_on_oom may not work if there is a process using
cpusets/mempolicy, because other nodes' memory may remain.
But some people want failover by panic ASAP even if they are used.
This patch
Paul Mackerras wrote:
Rik van Riel writes:
I guess we'll need to call tlb_remove_tlb_entry() inside the
MADV_FREE code to keep powerpc happy.
I don't see why; once ptep_test_and_clear_young has returned, the
entry in the hash table has already been removed.
OK, so this one won't be necessa
On Mon, 23 Apr 2007, Andrew Morton wrote:
On Tue, 24 Apr 2007 04:09:18 + (GMT) William Heimbigner <[EMAIL PROTECTED]>
wrote:
This bug occurs in linux-2.6.20 and 2.6.21-rc7-git5, and does not occur in
linux-2.6.19-git22.
After running "pktsetup 0 /dev/hdd", I get (timestamps removed):
pkt
Madhusudhan c wrote:
>
> Suppose a host controller is capable of suporting 8-bit and it tells
> the core that it can support 8-bit. Now the card that is plugged in
> might or might not support 8-bit based on the type of the card. There
> is no field in the ext_csd which will tell you what bus widt
> Further in general it doesn't make sense to grab a module reference
> and call that sufficient because we would like to request that the
> module exits.
Which is, btw, I think a total misdesign of our module stuff, but heh, I
remember that lead to some flamewars back then...
Like anything else
Ian Kirk wrote:
Hi,
I just wondered if the below type of crash was a known thing, and if
there are any obvious things I can do to prevent/fix it ?
BUG: spinlock bad magic on CPU#0, kswapd0/242 (Not tainted)
lock: c06c9380, .magic: c06c9380, .owner:
[] _raw_spin_lock+0x1a/0xd9
[] _spin_lock_irqs
David Schwartz пишет:
You have a misunderstanding about the semantics of 'sendfile'. The 'sendfile'
function is just a more efficient version of a read followed by a write. If you
did a read followed by a write, it would block as well (in the read).
DS
sendfile function is not just a more e
Paul Mackerras <[EMAIL PROTECTED]> writes:
> Eric W. Biederman writes:
>
>> Well the basic problem is that for any piece of code that can be modular
>> we need a way to ensure all threads it has running are shutdown when we
>> remove the module.
>
> The EEH code can't be modular, and wouldn't make
> Within reason, it's not the number of clients that X has that causes its
> CPU bandwidth use to sky rocket and cause problems. It's more to to
> with what type of clients they are. Most GUIs (even ones that are
> constantly updating visual data (e.g. gkrellm -- I can open quite a
> large n
On Monday 23 April 2007, Paul Sokolovsky wrote:
> Hello David,
>
> Thursday, April 19, 2007, 5:22:44 AM, you wrote:
>
> >> >> > So, talking about what an (optional) implementation framework might
> >> >> > look like (and which could handle the SOC, FPGA, I2C, and MFD cases
> >> >> > I've looked a
David Miller wrote:
From: voron <[EMAIL PROTECTED]>
Date: Tue, 24 Apr 2007 00:13:27 +0300
As I see, nonblocking mode is enabled - sendfile sends less than asked.
The socket is marked as non-blocking, but the disk I/O is not.
It's blocking on the disk I/O not the socket part of the o
Rik van Riel writes:
> I guess we'll need to call tlb_remove_tlb_entry() inside the
> MADV_FREE code to keep powerpc happy.
I don't see why; once ptep_test_and_clear_young has returned, the
entry in the hash table has already been removed. Adding the
tlb_remove_tlb_entry call certainly won't do
On Mon, 2007-04-23 at 17:55 -0400, Bill Davidsen wrote:
> Based on just this script as load I would say renice on X isn't a good
> thing. Based on one small test, I would say that renice of X in
> conjunction with heavy disk i/o and a single fast scrolling xterm (think
> kernel compile) seems t
Eric W. Biederman writes:
> Well the basic problem is that for any piece of code that can be modular
> we need a way to ensure all threads it has running are shutdown when we
> remove the module.
The EEH code can't be modular, and wouldn't make any sense to be
modular, since it's part of the infr
oom_kill_task() calls __oom_kill_task() to OOM kill a selected task.
When finding other threads that share an mm with that task, we need to
kill those individual threads and not the same one.
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: David Rientjes
Herbert Xu wrote:
> You don't need to disable BH in netif_poll since it's always called
> with BH disabled.
>
Ah, yes, you mentioned that before. I'll fix it up.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
Herbert Xu wrote:
> Thanks Jeremy. The patch looks good.
Could you give netfront an overall review as well? I know you're
already pretty familiar with it, but if you could cast a fresh eye over
it, that would be helpful.
Thanks,
J
-
To unsubscribe from this list: send the line "unsubscribe
Not having tested it or anything, that looks good to me.
Thanks,
Roland
-
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
> I have to admit I still don't really understand all this. Is it
> documented somewhere?
I have explained it in public more than once, but I don't know off hand
anywhere that was helpfully recorded.
> What does "hwcap 0 nosegneg" actually mean? What does the "0" mean here?
ldconfig is usually
This bug occurs in linux-2.6.20 and 2.6.21-rc7-git5, and does not occur in
linux-2.6.19-git22.
After running "pktsetup 0 /dev/hdd", I get (timestamps removed):
pktcdvd: pkt_get_last_written failed
BUG: unable to handle kernel NULL pointer dereference at virtual address
000e
printing eip:
c
On Sat, 2007-04-21 at 11:48 +0200, Andi Kleen wrote:
> > Lots of people want kgdb. One person is famously less keen on it, but
> > we'll be able to talk him around, as long as the patches aren't daft.
>
> The big question is if the kgdb developers seriously want mainline.
> At least in the past t
Linus Torvalds wrote:
On Mon, 23 Apr 2007, Ingo Molnar wrote:
The "give scheduler money" transaction can be both an "implicit
transaction" (for example when writing to UNIX domain sockets or
blocking on a pipe, etc.), or it could be an "explicit transaction":
sched_yield_to(). This latter i'v
Jiri Kosina <[EMAIL PROTECTED]> wrote:
>
> Hmm, *sigh*. I guess the patch below fixes the problem, but it is a
> masterpiece in the field of ugliness. And I am not sure whether it is
> completely correct either. Are there any immediate ideas for better
> solution with respect to how struct sock
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> @@ -1212,10 +1212,10 @@ static int netif_poll(struct net_device
>int pages_flipped = 0;
>int err;
>
> - spin_lock(&np->rx_lock);
> + spin_lock_bh(&np->rx_lock);
>
>if (unlikely(!netfront_carrier_ok(np))) {
> -
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
> Not sure... I can see places where I might want to spawn an arbitrary
> number of these without having to preallocate structures... and if I
> allocate on the fly, then I need a way to free that structure when the
> kthread is reaped which I don
On Mon, 23 Apr 2007 22:53:49 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote:
> I don't see why we need the attached, but in case you find
> a good reason, here's my signed-off-by line for Andrew :)
Andew is in a defensive crouch trying to work his way through all the bugs
he's been sent. After I'v
On Friday April 20, [EMAIL PROTECTED] wrote:
> Scale writeback cache per backing device, proportional to its writeout speed.
So it works like this:
We account for writeout in full pages.
When a page has the Writeback flag cleared, we account that as a
successfully retired write for the relevan
On 4/24/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
On Tue, 24 Apr 2007, Satyam Sharma wrote:
> If I remember right, a very similar patchset was recently submitted
> that Andrew merged in -mm(?). It also renamed memclear_highpage_flush
> to something like zero_user_page (though I wonder how
>
> I am not in any way argue that your driver architecture is wrong or that you
> should change anything. My point was simple. [tifm_sd] can only work with
> [tifm_7xx1]. If you add support for let's say [tifm_8xx2] in the future, which
> would have port offsets different that [tifm_7xx1], you wo
Nick Piggin wrote:
What the tlb flush used to be able to assume is that the page
has been removed from the pagetables when they are put in the
tlb flush batch.
I think this is still the case, to a degree. There should be
no harm in removing the TLB entries after the page table has
been unlock
Hisashi Hifumi wrote:
At 22:42 07/04/23, Hugh Dickins wrote:
>On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
>> >No. The PG_lru flag bit is just one bit amongst many others:
>> >what of concurrent operations changing other bits in that same
>> >unsigned long e.g. trying to lock the page by sett
On Fri, 13 Apr 2007 11:31:16 +0400 Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> On top of Eric's
>
> kthread-dont-depend-on-work-queues-take-2.patch
>
> Currently kernel threads use sigprocmask(SIG_BLOCK) to protect against
> signals.
> This doesn't prevent the signal delivery, this only bl
On Mon, 2007-04-23 at 20:08 -0600, Eric W. Biederman wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> >> The only reason for using threads here is to get the error recovery
> >> out of an interrupt context (where errors may be detected), and then,
> >> an hour later, decrement a cou
Hi Matt,
On 4/24/07, Matt Ranon <[EMAIL PROTECTED]> wrote:
> The obvious question is: what's _wrong_ with doing all this in some
> cut-down userspace environment like busybox? Why is this stuff better?
>
> Obviously some embedded developers have considered that option and
> have rejected it. B
On Tue, 24 Apr 2007 10:54:27 +0900
Hisashi Hifumi <[EMAIL PROTECTED]> wrote:
> In the case that changing the same bit concurrently, lock prefix or other
> spinlock is needed. But, I think that concurrent bit operation on different
> bits
> is just like OR operation , so lock prefix is not needed.
On Tue, 24 Apr 2007, Satyam Sharma wrote:
> On 4/24/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > There are a series of open coded reimplementation of memclear_highpage_flush
> > all over the page cache code. Call memclear_highpage_flush in those
> > locations.
> > Consolidates code and eas
On Tue, 24 Apr 2007 07:49:45 +0530 "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
> On 4/24/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > There are a series of open coded reimplementation of memclear_highpage_flush
> > all over the page cache code. Call memclear_highpage_flush in those
> > loc
On 4/24/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
There are a series of open coded reimplementation of memclear_highpage_flush
all over the page cache code. Call memclear_highpage_flush in those locations.
Consolidates code and eases maintenance.
If I remember right, a very similar patch
Rik van Riel wrote:
This should fix the MADV_FREE code for PPC's hashed tlb.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
---
Nick Piggin wrote:
Nick Piggin wrote:
3) because of this, we can treat any such accesses as
happening simultaneously with the MADV_FREE and
as illegal, aka
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>> The only reason for using threads here is to get the error recovery
>> out of an interrupt context (where errors may be detected), and then,
>> an hour later, decrement a counter (which is how we limit these to
>> 6 per hour). Thread reaping i
Crispin Cowan wrote:
David Wagner wrote:
James Morris wrote:
[...] you can change the behavior of the application and then bypass
policy entirely by utilizing any mechanism other than direct filesystem
access: IPC, shared memory, Unix domain sockets, local IP networking,
remote ne
On Mon, Apr 23, 2007 at 05:59:06PM -0700, Li, Tong N wrote:
> I don't know if we've discussed this or not. Since both CFS and SD claim
> to be fair, I'd like to hear more opinions on the fairness aspect of
> these designs. In areas such as OS, networking, and real-time, fairness,
> and its more gen
This should fix the MADV_FREE code for PPC's hashed tlb.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
---
Nick Piggin wrote:
Nick Piggin wrote:
3) because of this, we can treat any such accesses as
happening simultaneously with the MADV_FREE and
as illegal, aka undefined behaviour te
At 22:42 07/04/23, Hugh Dickins wrote:
>On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
>> >No. The PG_lru flag bit is just one bit amongst many others:
>> >what of concurrent operations changing other bits in that same
>> >unsigned long e.g. trying to lock the page by setting PG_locked?
>> >There ar
On Monday 23 April 2007, Niel Lambrechts wrote:
>Gene Heskett wrote:
>> This message prompted me to do some checking in re context switches
>> myself, and I've come to the conclusion that there could be a bug in
>> vmstat itself.
>
>Perhaps. perhaps not. :)
>
>> Run singly the context switching is
[1] Summary:
Kernel Reports Oops: 0002 [1] SMP and the system becomes unstable
[2] Full Description:
Sometimes, randomly i get this Oops message and the system becomes
unstable. By unstable i mean all applications segmentation faults when i
execute (after the Oops). Sometimes X crashes, sometim
On Mon, Apr 23, 2007 at 02:57:00PM -0700, Jeremy Fitzhardinge wrote:
> Netfront's use of nh.raw and h.raw for storing page+offset is a bit
> hinky, and it breaks with upcoming network stack updates which reduce
> these fields to sub-pointer sizes. Fortunately, skb offers the "cb"
> field specifica
> The only reason for using threads here is to get the error recovery
> out of an interrupt context (where errors may be detected), and then,
> an hour later, decrement a counter (which is how we limit these to
> 6 per hour). Thread reaping is "trivial", the thread just exits
> after an hour.
In
On Mon, 23 Apr 2007, Amit Gud wrote:
On Mon, 23 Apr 2007, Arjan van de Ven wrote:
> The other thing which we should consider is that chunkfs really
> requires a 64-bit inode number space, which means either we only allow
does it?
I'd think it needs a "chunk space" number and a 32 bit loc
Roland McGrath wrote:
>> + * It should contain:
>> + * hwcap 0 nosegneg
>> + * to match the mapping of bit to name that we give here.
>>
>
> This needs to be "hwcap 0 nosegneg" to match:
>
>
>> +NOTE_KERNELCAP_BEGIN(1, 2)
>> +NOTE_KERNELCAP(1, "nosegneg")
>> +NOTE_KERNELCAP_END
>>
>
>
Simon Horman <[EMAIL PROTECTED]> writes:
> On Mon, Apr 23, 2007 at 12:04:01PM -0600, Eric W. Biederman wrote:
>> Simon Horman <[EMAIL PROTECTED]> writes:
>>
>> > Update the list information for kexec and kdump
>> >
>> > Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
>> >
>> > ---
>> > Is it too
On Mon, Apr 23, 2007 at 02:56:54PM -0700, Jeremy Fitzhardinge wrote:
> Implement a Xen back-end for hvc console.
>
> From: Gerd Hoffmann <[EMAIL PROTECTED]>
> Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
>
> ---
> arch/i386/xen/Kconfig |1
> arch/i386/xen/events.c|3 -
From: Roland McGrath <[EMAIL PROTECTED]>
wait* syscalls return -ECHILD even when an individual PID of a live child
was requested explicitly, when security_task_wait denies the operation.
This means that something like a broken SELinux policy can produce an
unexpected failure that looks just like a
On Mon, Apr 23, 2007 at 05:31:29PM -0700, H. Peter Anvin wrote:
> Heh. sys_read_tree() -- walk a directory tree and return it as a data
> structure in memory :)
But maybe you don't want every single file in the directory, but some
subset of the files in the directory tree. So before you know it
Rik van Riel wrote:
Use TLB batching for MADV_FREE. Adds another 10-15% extra performance
to the MySQL sysbench results on my quad core system.
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
---
Nick Piggin wrote:
3) because of this, we can treat any such accesses as
happening simultaneo
> (text reformatted to less than 80 cols. Please, we'll get along a lot
> better if you don't send 1000-column emails)
Sorry. I am afraid we are from a different background, and so very
poorly versed in these things. My email client does not seem
to have an option to tell it to format in 80 cols.
On Tue, 24 Apr 2007, Neil Brown wrote:
> kobject_set_name actually takes a format and arbitrary args and uses
> vsnprintf, so it has to make it's own copy.
Ok then this should be fine...
SLAB: Fix sysfs directory handling
This fixes the problem that SLUB does not track the names of aliased
slab
I don't know if we've discussed this or not. Since both CFS and SD claim
to be fair, I'd like to hear more opinions on the fairness aspect of
these designs. In areas such as OS, networking, and real-time, fairness,
and its more general form, proportional fairness, are well-defined
terms. In fact, p
David Wagner wrote:
> James Morris wrote:
>
>> [...] you can change the behavior of the application and then bypass
>> policy entirely by utilizing any mechanism other than direct filesystem
>> access: IPC, shared memory, Unix domain sockets, local IP networking,
>> remote networking etc.
>>
On Mon, Apr 23, 2007 at 12:04:01PM -0600, Eric W. Biederman wrote:
> Simon Horman <[EMAIL PROTECTED]> writes:
>
> > Update the list information for kexec and kdump
> >
> > Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
> >
> > ---
> > Is it too early for this change?
>
> It looks like the new l
On Monday April 23, [EMAIL PROTECTED] wrote:
> On Tue, 24 Apr 2007, Neil Brown wrote:
>
> > On Monday April 23, [EMAIL PROTECTED] wrote:
> > > Would this work? Contains a solution somewhat along the lines of your
> > > thoughts on the subject.
> > >
> >
> > Concept seems sound.
> > Code needs a
On Tue, 24 Apr 2007, Neil Brown wrote:
> On Monday April 23, [EMAIL PROTECTED] wrote:
> > Would this work? Contains a solution somewhat along the lines of your
> > thoughts on the subject.
> >
>
> Concept seems sound.
> Code needs a kfree of the name returned by create_unique_id, and I
> think
On Mon, 23 Apr 2007, Roland McGrath wrote:
> As I said in some earlier discussion following my original patch, that
> would be fine with me. I haven't coded up that variant, but it's simple
> enough. Would you like to do it?
Sure.
--
James Morris
<[EMAIL PROTECTED]>
-
To unsubscribe from thi
1 - 100 of 434 matches
Mail list logo
