On Sun, Mar 04, 2007 at 05:45:54PM +, Simon Arlott wrote:
> Fix several instances of dvb-core functions using mutex_lock_interruptible
> and returning -ERESTARTSYS where the calling function will either never
> retry or never check the return value.
>
> These cause a race condition with
On Tue, Mar 06, 2007 at 08:22:11PM -0800, Arjan van de Ven wrote:
> > How about using a reduced check, as is done for fd and environ? This
> > would allow root-running system monitors to still do their job.
> > Effectively, this changes the test from "is ptracing" to just "can
> > ptrace".
>
Herbert wrote:
> personally, I'd prefer to avoid hierarchical
> structures wherever possible,
Sure - avoid them if you like. But sometimes they work out rather
well. And file system API's are sometimes the best fit for them.
I'm all for choosing the simplest API topology that makes sense.
But
On Saturday 10 March 2007 11:49, Matt Mackall wrote:
> On Sat, Mar 10, 2007 at 11:34:26AM +1100, Con Kolivas wrote:
> > Ok, so some of the basics then. Can you please give me the output of 'top
> > -b' running for a few seconds during the whole affair?
>
> Here you go:
>
>
Hi Andrew
Please find take3 of this patch : Linus suggested to introduce a helper
function to factorize work done by most d_dname() implementations.
Thank you
[PATCH] VFS : Delay the dentry name generation on sockets and pipes.
1) Introduces a new method in 'struct dentry_operations'. This
On Fri, Mar 09, 2007 at 02:35:57PM -0800, Zach Brown wrote:
> + if (rw == WRITE && mapping->nrpages) {
> + int err = invalidate_inode_pages2_range(mapping,
> + offset >> PAGE_CACHE_SHIFT, end);
> + if (err && retval >= 0)
> +
On Sat, Mar 10, 2007 at 12:02:25PM +1100, Con Kolivas wrote:
> On Saturday 10 March 2007 09:12, Con Kolivas wrote:
> > On Saturday 10 March 2007 08:57, Willy Tarreau wrote:
> > > On Fri, Mar 09, 2007 at 03:39:59PM -0600, Matt Mackall wrote:
> > > > On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con
On Fri, Mar 09, 2007 at 11:27:07PM +0530, Srivatsa Vaddagiri wrote:
> On Fri, Mar 09, 2007 at 01:38:19AM +0100, Herbert Poetzl wrote:
> > > 2) you allow a task to selectively reshare namespaces/subsystems with
> > >another task, i.e. you can update current->task_proxy to point to
> > >a
On Fri, Mar 09, 2007 at 05:18:31PM -0500, Ryan Hope wrote:
> from what I understood, there is a performance loss in plugsched
> schedulers because they have to share code
> even if pluggable schedulers is not a viable option, being able to
> choose which one was built into the kernel would be
Jeff Garzik a écrit :
> Adrian Bunk wrote:
>> Subject: NCQ problem with ahci and Hitachi drive
>> References : http://lkml.org/lkml/2007/3/4/178
>> Submitter : Mathieu Bérard <[EMAIL PROTECTED]>
>> Status : unknown
>
> according to the last message in that thread, it sounds like ACPI and
On Saturday 10 March 2007 09:12, Con Kolivas wrote:
> On Saturday 10 March 2007 08:57, Willy Tarreau wrote:
> > On Fri, Mar 09, 2007 at 03:39:59PM -0600, Matt Mackall wrote:
> > > On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
> > > > On Saturday 10 March 2007 08:07, Con Kolivas
On Mar 10 2007 09:57, Rusty Russell wrote:
>On Fri, 2007-03-09 at 16:56 +1100, Rusty Russell wrote:
>> __builtin_types_compatible_p() has been around since gcc 2.95, and we
>> don't use it anywhere. This patch quietly fixes that.
>
>OK, many people complained that it needed a comment. Good
On Sat, Mar 10, 2007 at 11:34:26AM +1100, Con Kolivas wrote:
> On Saturday 10 March 2007 09:29, Matt Mackall wrote:
> > On Sat, Mar 10, 2007 at 09:18:05AM +1100, Con Kolivas wrote:
> > > On Saturday 10 March 2007 08:57, Con Kolivas wrote:
> > > > On Saturday 10 March 2007 08:39, Matt Mackall
On Fri, Mar 09, 2007 at 11:25:47AM -0800, Paul Jackson wrote:
> > Ease of use maybe. Scripts can be more readily used with a fs-based
> > interface.
>
> And, as I might have already stated, file system API's are a natural
> fit for hierarchically shaped data, especially if the nodes in the
>
On Friday 09 March 2007, Adam Kropelin wrote:
>Gene Heskett wrote:
>> On Thursday 08 March 2007, Gene Heskett wrote:
>>> Greetings;
>>>
>>> Belkin is being non-responsive to requests for updated drivers for
>>> their line of UPS's, all of which now have a USB port which is the
>>> Belkin
On Fri, Mar 09, 2007 at 11:44:22PM +0530, Srivatsa Vaddagiri wrote:
> On Fri, Mar 09, 2007 at 01:48:16AM +0100, Herbert Poetzl wrote:
> > > There have been various projects attempting to provide resource
> > > management support in Linux, including CKRM/Resource Groups and UBC.
> > let me note
Greg> On Fri, Mar 09, 2007 at 10:40:21AM -0500, John Stoffel wrote:
>>
>> Hi all,
>>
>> I've just compiled and installed 2.6.21-rc3 on my Dual CPU Dell
>> Precision 610MT system. Dual 550mhz Xeon, 768mb of RAM. Mix of SCSI,
>> ATA drives. I'm using the new ATA_ drivers for my PATA disks.
Duh... forgot the patches:
2.6.21-rc-usb-serial.patch
Description: two patches for usbserial oops on 2.6.21-rc3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all.
I'm also affected by this bug. I noticed it upgrading from Ubuntu Dapper
to Edgy, and now persist on Feisty.
I can't remember the latest kernel version I used on Dapper, but I'm
sure that the disk was parking fine!
Are we in front of a
On Saturday 10 March 2007 09:29, Matt Mackall wrote:
> On Sat, Mar 10, 2007 at 09:18:05AM +1100, Con Kolivas wrote:
> > On Saturday 10 March 2007 08:57, Con Kolivas wrote:
> > > On Saturday 10 March 2007 08:39, Matt Mackall wrote:
> > > > On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas
On Saturday 10 March 2007 10:06, Matt Mackall wrote:
> On Sat, Mar 10, 2007 at 10:02:37AM +1100, Con Kolivas wrote:
> > On Saturday 10 March 2007 09:29, Matt Mackall wrote:
> > > On Sat, Mar 10, 2007 at 09:18:05AM +1100, Con Kolivas wrote:
> > > > On Saturday 10 March 2007 08:57, Con Kolivas
On Fri, 9 Mar 2007, Al Boldi wrote:
My preferred sphere of operation is the Manichean domain of faster vs.
slower, functionality vs. non-functionality, and the like. For me, such
design concerns are like the need for a kernel to format pagetables so
the x86 MMU decodes what was intended, or
On Fri, Mar 09, 2007 at 03:15:10PM -0800, Linus Torvalds wrote:
>
>
> On Sat, 10 Mar 2007, Oleg Verych wrote:
> >
> > OTOH, if i would write it this way
> >
> > #define BALIGN(x,bits) x) >> (bits)) + 1) << (bits))
>
> But that's *wrong*. It aligns something that is *already* aligned
On Sat, 10 Mar 2007, Jan Engelhardt wrote:
>
> On Mar 9 2007 15:39, Davide Libenzi wrote:
> >
> >This patch add an anonymous inode source, to be used for files that need
> >and inode only in order to create a file*. We do not care of having an
> >inode for each file, and we do not even care of
William Lee Irwin III wrote:
>> The short translation of my message for you is "Linus, please don't
>> LART me too hard."
On Fri, Mar 09, 2007 at 11:43:46PM +0300, Al Boldi wrote:
> Right.
Given where the code originally came from, I've got bullets to dodge.
William Lee Irwin III wrote:
>>
Keep trying, you might hit the proper mailing list after a
few more attempts. :-)
Please post networking issues to netdev@vger.kernel.org,
thank you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On 3/8/07, Parav K Pandit <[EMAIL PROTECTED]> wrote:
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Luong Ngo
Sent: Friday, March 09, 2007 8:54 AM
To: Robert Hancock
Cc: linux-kernel; [EMAIL PROTECTED]
Subject: Re: Sleeping thread not receive signal
On Fri, Mar 09, 2007 at 03:46:40PM -0800, Stephen Hemminger wrote:
> The dma_ops structure can be const since it never changes
> after boot.
Sounds reasonable. I haven't come up with a likely case where we would
want to change a dma_ops structure (as opposed to just pointing to a
different
On Fri, 2007-09-03 at 13:19 -0800, Pavel Machek wrote:
> Hi!
>
> >
> > -void set_console(int nr)
> > +extern char vt_dont_switch;
> > +
>
> What does this variable do and why do we want to use it here?
>
It's needed in set_console(). Console switch will fail if this is true.
> 'if ('
>
> >
Hello-
Cliff Wickman wrote:
> This patch would insert a preference to migrate such a task to a cpu within
> its cpuset (and set its cpus_allowed to its cpuset).
>
> With this patch, migrate the task to:
> 1) to any cpu on the same node as the disabled cpu, which is both online
> and among
On Mar 9 2007 15:39, Davide Libenzi wrote:
>
>This patch add an anonymous inode source, to be used for files that need
>and inode only in order to create a file*. We do not care of having an
>inode for each file, and we do not even care of having different names in
>the associated dentries
I read the code and found that a block buffer is not necessarily freed
even if the corresponding inode is released. Looks like block buffer
can stay around as long as the system still has free memory. Is my
understanding correct?
-x
On 3/9/07, Xin Zhao <[EMAIL PROTECTED]> wrote:
Hi,
I am
The dma_ops structure can be const since it never changes
after boot.
Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/pci-calgary.c |2 +-
arch/x86_64/kernel/pci-gart.c|2 +-
arch/x86_64/kernel/pci-nommu.c |2 +-
arch/x86_64/kernel/pci-swiotlb.c |
On 03/09, Roland McGrath wrote:
>
> > Yes sure, this change shoud be tested in -mm tree (I'll send the patch
> > on Sunday after some testing). The only (afaics) problem is that with
> > this change a kernel thread must not do do_fork(CLONE_THREAD).
>
> To clarify, the danger here is that an
This patch implement the necessary compat code for the timerfd system call.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.20.ep2/fs/compat.c
===
--- linux-2.6.20.ep2.orig/fs/compat.c 2007-03-09 12:56:04.0
This patch wire the timerfd system call to the x86_64 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.20.ep2/arch/x86_64/ia32/ia32entry.S
===
--- linux-2.6.20.ep2.orig/arch/x86_64/ia32/ia32entry.S
This patch introduces a new system call for timers events delivered
though file descriptors. This allows timer event to be used with
standard POSIX poll(2), select(2) and read(2). As a consequence of
supporting the Linux f_op->poll subsystem, they can be used with
epoll(2) too.
The system call is
This patch wire the timerfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.20.ep2/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.20.ep2.orig/arch/i386/kernel/syscall_table.S
This patch add an anonymous inode source, to be used for files that need
and inode only in order to create a file*. We do not care of having an
inode for each file, and we do not even care of having different names in
the associated dentries (dentry names will be same for classes of file*).
This patch series implements the new signalfd() and signalfd_dequeue()
system calls. I took part of the original Linus code (and you know how
badly it can be broken :), and I added even more breakage ;)
Signals are fetched from the same signal queue used by the process,
so signalfd will compete
This patch wire the signalfd system call to the i386 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.20.ep2/arch/i386/kernel/syscall_table.S
===
--- linux-2.6.20.ep2.orig/arch/i386/kernel/syscall_table.S
This patch implement the necessary compat code for the signalfd system call.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.20.ep2/fs/compat.c
===
--- linux-2.6.20.ep2.orig/fs/compat.c 2007-03-09 10:43:18.0
This patch wire the signalfd system call to the x86_64 architecture.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.20.ep2/include/asm-x86_64/unistd.h
===
--- linux-2.6.20.ep2.orig/include/asm-x86_64/unistd.h
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> The important part is that there's more to the story than just pv_ops.
> If you wanted to make such a change, then you'd need to refactor the
> i386 support code to add a vma->paging helper layer. That layer would
> be available for any
Ingo Molnar wrote:
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
[...] If that is the case then my ABI worries would indeed be wrong
and i'd owe Zach a big fat apology [and more] for my flames ;-)
that apology i very much owe to Zach no matter what the outcome of the
discussion. Zach,
Hi!
> > You're better off using the VGA console, and lettign X re-initialize the
> > graphics device. That generally at least has a reasonably good chance of
> > working.
> >
> > Re-initializing graphics modes really is very hard. You can try with the
> > BIOS video hack (I forget the kernel
On Fri, Mar 09, 2007 at 10:39:13AM +, Christoph Hellwig wrote:
> > One problem with this interface is that it cannot be used to write into the
> > filesystem by any means other than already-initialised buffers via iovecs.
> > So
> > prepare/commit have to stay around for non-user data...
>
On 09/03/07 20:42, Francois Romieu wrote:
Simon Arlott <[EMAIL PROTECTED]> :
When I unplug the cable the system just stops responding to anything,
at all. No message is printed to the console when the cable is plugged
back in.
rtl8139_interrupt (spin_lock(>lock))
-> rtl8139_weird_interrupt
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]>
> 2007-03-09 11:25
> > > > + }
> > > > + } else {
> > > > + /* We're not a multi-queue device. */
> > > > + spin_lock(>queue_lock);
> > > > + q =
How does the clock period get set on periodic timers? In my clock
driver, I'm seeing a call to ->set_mode(CLOCK_EVT_MODE_PERIODIC, evt),
but then... nothing. I was expecting a call to set_next_event to set
the timer period.
The calltrace is:
#0 xen_new_set_mode (mode=CLOCK_EVT_MODE_PERIODIC,
Am Mittwoch, 7. März 2007 20:48 schrieb Mws:
> hi all,
>
> i just moved my win tv dvb-s card (PCI) from my old to my actual pc.
>
> its an ASUS M2N32 WS Professional AMD64 X2 Board equiped with
> the nvidia nForce 590 SLI MCP chipset.
>
> in the past, i had to use the noapic kernel cmdline param
Ingo Molnar wrote:
ok, sure, how about the one i mentioned: long-term i'd like to have a
paravirt model where the guest does not store /any/ page tables - all
paging is managed by the hypervisor. The guest has a vma tree, but
otherwise it does not process pagefaults, has no concept of a pte
On Sat, Mar 10, 2007 at 10:02:37AM +1100, Con Kolivas wrote:
> On Saturday 10 March 2007 09:29, Matt Mackall wrote:
> > On Sat, Mar 10, 2007 at 09:18:05AM +1100, Con Kolivas wrote:
> > > On Saturday 10 March 2007 08:57, Con Kolivas wrote:
> > > > On Saturday 10 March 2007 08:39, Matt Mackall
On Sat, 10 Mar 2007, Oleg Verych wrote:
>
> OTOH, if i would write it this way
>
> #define BALIGN(x,bits) x) >> (bits)) + 1) << (bits))
But that's *wrong*. It aligns something that is *already* aligned to
something else.
So you'd have to do it as something like
#define
On Sat, 10 Mar 2007, Rusty Russell wrote:
> On Fri, 2007-03-09 at 16:56 +1100, Rusty Russell wrote:
> > __builtin_types_compatible_p() has been around since gcc 2.95, and we
> > don't use it anywhere. This patch quietly fixes that.
>
> OK, many people complained that it needed a comment. Good
> I argue that you can count the users (who aren't on 2.4) on one hand, and
> developers don't seem to have cared for it in ages.
Rather than ask on mailing-lists, it's probably easier to just make the jffs
compilation fail (with a #error). This way, if someone uses it, he'll bump
into it, no
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> [...] If that is the case then my ABI worries would indeed be wrong
> and i'd owe Zach a big fat apology [and more] for my flames ;-)
that apology i very much owe to Zach no matter what the outcome of the
discussion. Zach, some of my mindless
Perhaps this patch can go into Wesnoth for testing for a while before
we merge it into the 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
On Fri, 2007-03-09 at 10:15 +0200, Pekka J Enberg wrote:
> +static int revoke_vma(struct vm_area_struct *vma, struct zap_details
> *details)
> +{
> + unsigned long restart_addr, start_addr, end_addr;
> + int need_break;
> +
> + start_addr = vma->vm_start;
> + end_addr =
* Chris Wright <[EMAIL PROTECTED]> wrote:
> > ok, sure, how about the one i mentioned: long-term i'd like to have
> > a paravirt model where the guest does not store /any/ page tables -
> > all paging is managed by the hypervisor. The guest has a vma tree,
> > but otherwise it does not
Hello,
I periodically see the following TCP kernel assertion errors in
/var/log/message
(it does seem that networking is eventually able to recover from these
errors):
kernel: KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c
(1171)
kernel: KERNEL: assertion (flags &
Eric W. Biederman wrote:
[CHOP]
Below is an additional set of warnings that should help debug this.
The old code just got lucky that it triggered a warning when this happens.
I'm trying this patch together with the other 2 that you sent out a few days
ago. I'm seeing some minor issues with
Linus Torvalds wrote:
but ... maybe because VMI is so lowlevel and covers /all/ of x86 today,
it will always be able to emulate whatever different concept we can come
up with? Do we really know this absolutely sure?
"For sure"? Absolutely not. But since any new interfaces we come up with
On Wed, Mar 07, 2007 at 08:38:27AM -0800, Linus Torvalds wrote:
>
>
> On Wed, 7 Mar 2007, Oleg Verych wrote:
> >
> > Probably it can be used to get rid of gccisms and "type fluff" due to
> > bitwise arithmetics in ALIGN?
>
> Hell no.
>
> The typeof is there to make sure we have the right type,
On Sat, 10 Mar 2007 09:57:32 +1100 Rusty Russell wrote:
> On Fri, 2007-03-09 at 16:56 +1100, Rusty Russell wrote:
> > __builtin_types_compatible_p() has been around since gcc 2.95, and we
> > don't use it anywhere. This patch quietly fixes that.
Bah. Just because gcc has a "feature" doesn't
On Saturday 10 March 2007 09:29, Matt Mackall wrote:
> On Sat, Mar 10, 2007 at 09:18:05AM +1100, Con Kolivas wrote:
> > On Saturday 10 March 2007 08:57, Con Kolivas wrote:
> > > On Saturday 10 March 2007 08:39, Matt Mackall wrote:
> > > > So what's different between makes in parallel and make -j
On Mar 9 2007 23:23, Sam Ravnborg wrote:
>Date: Fri, 9 Mar 2007 23:23:32 +0100
>From: Sam Ravnborg <[EMAIL PROTECTED]>
>To: Jan Engelhardt <[EMAIL PROTECTED]>,
>Paulo Marques <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED], Christoph Hellwig <[EMAIL PROTECTED]>,
>Deepak Saxena <[EMAIL
* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-03-09 11:25
> > > + }
> > > + } else {
> > > + /* We're not a multi-queue device. */
> > > + spin_lock(>queue_lock);
> > > + q = dev->qdisc;
> > > + if
On Fri, 2007-03-09 at 16:56 +1100, Rusty Russell wrote:
> __builtin_types_compatible_p() has been around since gcc 2.95, and we
> don't use it anywhere. This patch quietly fixes that.
OK, many people complained that it needed a comment. Good point!
==
Add comment to ARRAY_SIZE macro.
Alistair John Strachan wrote:
I lean towards "yes", since it is a needed-by-hardware fix, but I also
am interested in testing feedback since it is so late in the 2.6.21-rc
game.
I would lean toward that as well, but it would be good to get some
testing from some sata_nv ADMA users to make sure
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> > but ... maybe because VMI is so lowlevel and covers /all/ of x86
> > today, it will always be able to emulate whatever different concept
> > we can come up with? Do we really know this absolutely sure?
>
> "For sure"? Absolutely not. But since
On 3/9/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
I think the sound example to the right really shows it. /dev/dsp has a
consistent ABI on a ton of systems. The API below it, varies. Linux got
file_operations and ALSA. Solaris/BSD may have its
vnode-and-so-on-functions and some sort of OSS.
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> * Chris Wright <[EMAIL PROTECTED]> wrote:
> > i'm not really one to argue on behalf of VMI, but i don't think it's
> > as dire make it out. [...]
>
> hey, that's what i thought when i helped do the vDSO, until i got
> slapped with cold reality called
On Fri 2007-03-09 23:34:00, Rafael J. Wysocki wrote:
> On Friday, 9 March 2007 23:13, Pavel Machek wrote:
> > Hi!
> >
> > > > > Index: linux-2.6.21-rc3/kernel/power/user.c
> > > > > ===
> > > > > ---
[ cc:ing Alan who may have a better idea what is wrong with this CF than me ]
On Friday 09 March 2007, Marco Lazzarotto wrote:
> Hallo! :-)
>
> Bartlomiej Zolnierkiewicz ha scritto:
> > Czesc!
> >
> > On Tuesday 06 March 2007, Marco Lazzarotto wrote:
> >
> >>Ciao!
> >>
> >>Bartlomiej
> scsi1 : ata_piix
> ata2: port disabled. ignoring.
> ata2: reset failed, giving up<--- THIS IS NEW.
>
> However, I think it's just bogus as there is ata2 is disabled on this laptop.
This is expected behaviour and it is what every controller except the
PIIX has done for some time. I'm not
On Sat, Mar 10, 2007 at 09:18:05AM +1100, Con Kolivas wrote:
> On Saturday 10 March 2007 08:57, Con Kolivas wrote:
> > On Saturday 10 March 2007 08:39, Matt Mackall wrote:
> > > On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
> > > > On Saturday 10 March 2007 08:07, Con Kolivas wrote:
Ingo Molnar wrote:
> ok, sure, how about the one i mentioned: long-term i'd like to have a
> paravirt model where the guest does not store /any/ page tables - all
> paging is managed by the hypervisor. The guest has a vma tree, but
> otherwise it does not process pagefaults, has no concept of a
On Sat, Mar 10, 2007 at 09:12:07AM +1100, Con Kolivas wrote:
> On Saturday 10 March 2007 08:57, Willy Tarreau wrote:
> > On Fri, Mar 09, 2007 at 03:39:59PM -0600, Matt Mackall wrote:
> > > On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
> > > > On Saturday 10 March 2007 08:07, Con
dio: invalidate clean pages before dio write
This patch fixes a user-triggerable oops that was reported by Leonid Ananiev as
archived at http://lkml.org/lkml/2007/2/8/337.
dio writes invalidate clean pages that intersect the written region so that
subsequent buffered reads go to disk to read the
On Friday, 9 March 2007 23:13, Pavel Machek wrote:
> Hi!
>
> > > > Index: linux-2.6.21-rc3/kernel/power/user.c
> > > > ===
> > > > --- linux-2.6.21-rc3.orig/kernel/power/user.c
> > > > +++ linux-2.6.21-rc3/kernel/power/user.c
> > > >
Hi, I am encountering a performance problem, which I have tracked into the
Linux kernel. The problem occurs with my experimental web server that uses
sendfile to repeatedly transmit files. The files are based on the static
portion of the SPECweb99 fileset and range in size to model a
On Sat, Mar 10, 2007 at 09:12:07AM +1100, Con Kolivas wrote:
(...)
> > Matt, could you check with plain 2.6.20 + Con's patch ? It is possible
> > that he added bugs when porting to -mm, or that someting in -mm causes
> > the trouble. Your experience with -mm seems so much different from mine
> >
Ingo Molnar wrote:
> yep. That's precisely my worry. And it doesnt have to be a 'great' thing
> - just any random small change in the kernel that makes sense: what is
> the likelyhood that it cannot be implemented, no matter what amount of
> insight, paravirt_ops + hyper-ABI emulation hackery,
* Chris Wright <[EMAIL PROTECTED]> wrote:
> * Ingo Molnar ([EMAIL PROTECTED]) wrote:
> > i am worried whether /any/ future change to the upstream kernel's design
> > can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
> > mean truly any. And whether that can be done is not
On Fri, 9 Mar 2007, Ingo Molnar wrote:
>
> hm. So your point is that VMI is in essence a Turing machine (a
> near-complete one)? No matter what redesign we do on the Linux side, the
> VMI paravirt_ops will always be able to adopt to it?
No, I don't think it's turing-complete ;)
But since it
On Fri, Mar 09, 2007 at 09:16:35PM +0100, Jan Engelhardt wrote:
>
> On Mar 9 2007 20:00, Sam Ravnborg wrote:
> >On Thu, Mar 08, 2007 at 11:01:57PM +0100, Jan Engelhardt wrote:
> >>
> >> Since Solaris seems to be on the run, I did myself try compile it.
> >> However, unlike the original poster
Hi,
I am working on a file system that allow multiple files to share data
blocks. That is, a data block can be shared by two or more files. Now
my question is: suppose file A and B share the same data block D. Now
a process open file A and read block D, then this process closes file
A. If
Andrew Morton wrote:
> > On Mon, 26 Feb 2007 17:48:55 -0600 Marc St-Jean
> <[EMAIL PROTECTED]> wrote:
> > [PATCH] drivers: PMC MSP71xx LED driver
> >
> > Patch to add LED driver for the PMC-Sierra MSP71xx devices.
> >
> > This patch references some platform support files previously
> >
On Saturday 10 March 2007 08:57, Con Kolivas wrote:
> On Saturday 10 March 2007 08:39, Matt Mackall wrote:
> > On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
> > > On Saturday 10 March 2007 08:07, Con Kolivas wrote:
> > > > On Saturday 10 March 2007 07:46, Matt Mackall wrote:
> > > >
from what I understood, there is a performance loss in plugsched
schedulers because they have to share code
even if pluggable schedulers is not a viable option, being able to
choose which one was built into the kernel would be easy (only takes a
few ifdefs), i too think competition would be
On Saturday 10 March 2007 08:57, Willy Tarreau wrote:
> On Fri, Mar 09, 2007 at 03:39:59PM -0600, Matt Mackall wrote:
> > On Sat, Mar 10, 2007 at 08:19:18AM +1100, Con Kolivas wrote:
> > > On Saturday 10 March 2007 08:07, Con Kolivas wrote:
> > > > On Saturday 10 March 2007 07:46, Matt Mackall
Hi!
> > > Index: linux-2.6.21-rc3/kernel/power/user.c
> > > ===
> > > --- linux-2.6.21-rc3.orig/kernel/power/user.c
> > > +++ linux-2.6.21-rc3/kernel/power/user.c
> > > @@ -402,9 +402,10 @@ static int snapshot_ioctl(struct inode *
>
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Now it may be that you've got a change that's absolutely great for
> everyone, and the only blocker is that the FoobieVisor can't deal with
> it. OK, great, then you'd have a point.
yep. That's precisely my worry. And it doesnt have to be a
* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> i am worried whether /any/ future change to the upstream kernel's design
> can be adopted via paravirt_ops, via the current VMI ABI. And by /any/ i
> mean truly any. And whether that can be done is not a function of the
> flexibility of paravirt_ops,
When booting my laptop with a 2.6.20.1 laptop with lockdep enabled to test my
code, I got a lockdep warning on pktcdvd on setup. It seems that do_open on a
pktcdvd device causes another do_open on the underlying device, and that
mutex_lock_nested is called with the same subclass (the for_part
Hi!
> > ...so, if pm_ops is non-null, power_down does nonboot cpu disabling,
> > otherwise we proceed with cpus enabled?
> >
> > That looks ugly.
> >
> > Is the warning bogus? Or maybe we should *always* disable nonboot cpus
> > in powerdown path?
>
> Is disable_nonboot_cpus() assuming that
On 3/9/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
1. What is the fundamental unit over which resource-management is
applied? Individual tasks or individual containers?
/me thinks latter.
Yes
In which case, it makes sense to stick
resource control information in the
> the emphasis here is on 'from inside' which basically
> boils down to the following:
>
> if you create a 'resource container' to limit the
> usage of a set of resources for the processes
> belonging to this container, it would be kind of
> defeating the purpose, if you'd allow the processes
On 9 Mar 2007, at 12:52, Nick Piggin wrote:
Hi Christoph,
On Fri, Mar 09, 2007 at 10:39:13AM +, Christoph Hellwig wrote:
Hi Nick,
sorry for my later reply, this has been on my to answer list for
the last
month and I only managed to get back to it now.
No worries, I haven't had much
101 - 200 of 1046 matches
Mail list logo
