On Wed, 2007-02-21 at 18:51 +0100, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> This patch makes writing to shared memory mappings update st_ctime and
> st_mtime as defined by SUSv3:
>
>The st_ctime and st_mtime fields of a file that is mapped with
>MAP_SHARED and
> > Inspired by Peter Staubach's patch and the resulting comments.
> >
> >
>
> An updated version of the original patch was submitted to LKML
> yesterday... :-)
Strange coincidence :)
> > file = vma->vm_file;
> > start = vma->vm_end;
> > + mapping_update_tim
> > This flag is checked in msync() and __fput(), and if set, the file
> > times are updated and the flag is cleared
>
> Why not also check inside vfs_getattr?
This is the minimum, that the standard asks for.
Note, your porposal would touch the times in vfs_getattr(), which
means, that the modif
On Wed, 2007-02-21 at 19:28 +0100, Miklos Szeredi wrote:
> > > This flag is checked in msync() and __fput(), and if set, the file
> > > times are updated and the flag is cleared
> >
> > Why not also check inside vfs_getattr?
>
> This is the minimum, that the standard asks for.
>
> Note, your por
Trond Myklebust wrote:
On Wed, 2007-02-21 at 19:28 +0100, Miklos Szeredi wrote:
This flag is checked in msync() and __fput(), and if set, the file
times are updated and the flag is cleared
Why not also check inside vfs_getattr?
This is the minimum, that the standard asks for
> > > > This flag is checked in msync() and __fput(), and if set, the file
> > > > times are updated and the flag is cleared
> > >
> > > Why not also check inside vfs_getattr?
> >
> > This is the minimum, that the standard asks for.
> >
> > Note, your porposal would touch the times in vfs_getatt
Miklos Szeredi wrote:
Inspired by Peter Staubach's patch and the resulting comments.
An updated version of the original patch was submitted to LKML
yesterday... :-)
Strange coincidence :)
file = vma->vm_file;
start = vma->vm_end;
+
> >>> Inspired by Peter Staubach's patch and the resulting comments.
> >>>
> >>>
> >>>
> >> An updated version of the original patch was submitted to LKML
> >> yesterday... :-)
> >>
> >
> > Strange coincidence :)
> >
> >
> >>> file = vma->vm_file;
> >>> start
> From: Andrew Morton
> Newsgroups: gmane.linux.raid,gmane.linux.kernel
> Subject: Re: [PATCH 006 of 6] md: Add support for reshape of a raid6
> Date: Wed, 21 Feb 2007 14:48:06 -0800
Hallo.
> On Tue, 20 Feb 2007 17:35:16 +1100
> NeilBrown <[EMAIL PROTECTED]> wrote:
>
>> +for (i = conf
On Thu, 22 Feb 2007 00:36:22 +0100
Oleg Verych <[EMAIL PROTECTED]> wrote:
> > From: Andrew Morton
> > Newsgroups: gmane.linux.raid,gmane.linux.kernel
> > Subject: Re: [PATCH 006 of 6] md: Add support for reshape of a raid6
> > Date: Wed, 21 Feb 2007 14:48:06 -0800
>
> Hallo.
>
> > On Tue, 20 Feb
On Thursday, 22 February 2007 00:58, Andrew Morton wrote:
> On Thu, 22 Feb 2007 00:36:22 +0100
> Oleg Verych <[EMAIL PROTECTED]> wrote:
>
> > > From: Andrew Morton
> > > Newsgroups: gmane.linux.raid,gmane.linux.kernel
> > > Subject: Re: [PATCH 006 of 6] md: Add support for reshape of a raid6
> > >
Patch 1/2
This patch changes the way we determine if a logical volume is larger than 2TB.
The
original test looked for a total_size of 0. Originally we added 1 to the
total_size.
That would make our read_capacity return size 0 for >2TB lv's. We assumed that
we
could not have a lv size of 0 so i
Patch 2/2
This patch adds reboot_notifier support to cciss. Changes in firmware make this
patch
essential. Without this patch there may be valid data left in the controller's
battery
backed write cache (BBWC) on shutdown. We found out the hard way that the
kernel does
not call our cleanup routi
On Wed, Feb 21, 2007 at 03:12:28AM -0800, Roland McGrath wrote:
> The way I've organized my patch series is with the arch support split up
> along with the separate infrastructure patches in the series. That is,
> just asm/tracehook.h with no utrace_regset stuff in the first patch so that
> the ke
These are 2.6.21 material, nothing urgent.
Jeff
-
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:/
Move the host_info string from util.c to um_arch.c, where it is
actually initialized and used. Also document its lack of locking.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/include/os.h|2 +-
arch/um/include/user_util.h |2 --
arch/um/kernel/um_arch.c|6 +
Formatting fixes -
style violations
whitespace breakage
emacs formatting comment removal
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/kernel/um_arch.c | 51 +--
arch/um/os-Linux/main.c | 11 +
arch/um/sys-i3
Add some locking to host_ldt_entries to prevent racing when reading
LDT information from the host.
Also fixed some style violations.
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
arch/um/sys-i386/ldt.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
Ind
Get rid of a bunch of unused stuff -
cpu_feature had no users
linux_prog is little-used, so its declaration is moved to the
user for easy deletion when the whole file goes away
a long-unused debugging aid in helper.c is gone
Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
On Wednesday 21 February 2007 21:25, Jeff Dike wrote:
> Add some locking to host_ldt_entries to prevent racing when reading
> LDT information from the host.
Please remove GFP_KERNEL allocation under spin_lock - simplest way is using a
mutex unless this can be important for performance.
> @@ -386
On Thursday 08 February 2007 22:57, Jeff Dike wrote:
> x86_64 needs some TLS fixes. What was missing was remembering the
> child thread id during clone and stuffing it into the child during
> each context switch.
>
> The %fs value is stored separately in the thread structure since the
> host contr
On Thursday 15 February 2007 18:07, Jeff Dike wrote:
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
[...]
> @@ -331,10 +334,9 @@ void maybe_sigio_broken(int fd, int read
>
> sigio_lock();
> err = need_poll(&all_sigio_fds, all_sigio_fds.used + 1);
> - if(err){
> - printk(
On Wednesday February 21, [EMAIL PROTECTED] wrote:
> On Tue, 20 Feb 2007 17:35:16 +1100
> NeilBrown <[EMAIL PROTECTED]> wrote:
>
> > + for (i = conf->raid_disks ; i-- ; ) {
>
> That statement should be dragged out, shot, stomped on then ceremonially
> incinerated.
An experiment in lat
On Friday February 16, [EMAIL PROTECTED] wrote:
> I was wondering if the block layer has been changed into a more serialized
> manner yet? I've been trying to google this, but so far no luck. I know there
> was some talk about removing the stack based approach, but I can't find any
> information ab
On Tue, 20 Feb 2007 09:02:53 +0100 (CET), Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Feb 2007, Veronique & Vincent wrote:
> > Hi again Marcel and Jiri,
> > I've set up the hid-core.c to DEBUG mode... and it literally got pretty
> > verbose...
> thanks for the output. Is this really the
cond_resched() checks and conditionally sets PREEMPT_ACTIVE flag for
the current task. The comments says,
/*
* The BKS might be reacquired before we have dropped
* PREEMPT_ACTIVE, which could trigger a second
* cond_resched() call.
*/
My understanding is that cond_resched() would be indirectly i
On Wed, Feb 21, 2007 at 06:26:57PM -0800, Andrew Morton wrote:
> On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote:
>
> > > I can't say more until I've managed to understand your description, which
> > > might take a while.
> >
> > It is intended for reallocation of a buffe
On Wed, Feb 21, 2007 at 12:23:44PM -0800, Andrew Morton wrote:
> On Fri, 16 Feb 2007 18:08:42 -0800
> > +int select_nohz_load_balancer(int stop_tick)
> > +{
> > + int cpu = smp_processor_id();
> > +
> > + if (stop_tick) {
> > + cpu_set(cpu, nohz.cpu_mask);
> > + cpu_rq(cpu)
On Fri, Feb 16, 2007 at 06:08:42PM -0800, Suresh B wrote:
> Changes since v1:
>
> - Move the idle load balancer selection from schedule()
> to the first busy scheduler_tick() after restarting the tick.
> This will avoid the unnecessay ownership changes when
> softirq's(which are run
On Wed, Feb 21, 2007 at 02:15:10AM -0800, Roland McGrath wrote:
> > This causes the following compile error with CONFIG_PTRACE=y,
> > CONFIG_PROC_FS=n:
>
> Bah. I moved ptrace_may_attach to fs/proc/base.c so that CONFIG_PTRACE=n
> could just omit kernel/ptrace.c entirely and still get the functi
On Wed, Feb 21, 2007 at 02:13:38PM +0100, Rolf Eike Beer wrote:
> These functions were inlines before 8b9365d753d9870bb6451504c13570b81923228f.
> Now EXPORT_SYMBOL() them to allow them to be used in modules again.
Just because they happened to be inlined that doesn't mean modules should
be using t
On Thu, Feb 22, 2007 at 01:48:00PM +1100, Neil Brown wrote:
> Might this:
>http://lkml.org/lkml/2007/2/10/22
>
> relate to your question?
> If you are talking about stacking block device (via dm or md), then a
> patch to fix this in in -mm but there are or were some potential
> issues in dm th
Hi,
Following this message (on the RTC list) are six patches:
- Remove the /sys/class/rtc-dev class_device, and a class_interface
- Use "struct rtc_device" in the external interface, not class_device
- Simplify the sysfs attribute handling, removing a class_interface
- Simplify the /proc/driv
On Thursday February 22, [EMAIL PROTECTED] wrote:
> On Thu, Feb 22, 2007 at 01:48:00PM +1100, Neil Brown wrote:
> > Might this:
> >http://lkml.org/lkml/2007/2/10/22
> >
> > relate to your question?
> > If you are talking about stacking block device (via dm or md), then a
> > patch to fix this
RTC class suspend/resume support, re-initializing the system clock on resume
from the clock used to initialize it at boot time.
- Inlining the same code used by ARM, which saves and restores the
delta between a selected RTC and the current system wall-clock time.
- Removes calls to that ARM
On Tuesday 20 February 2007 2:07 pm, Rafael J. Wysocki wrote:
> > Plus, I'd guess, the old rtc driver statically linked.
>
> Yes (mistakenly).
Until someone merges the BSOD-for-Linux patch, I'll continue to
assume that oopsing is the wrong response to "user" mistakes. ;)
Legacy drivers can be
Is this Problem still investigated? I got the same kernel bug a few
minutes after booting my system with 2.6.20-mm2. As a student i am not
yet as familiar with kernel programming as i want to be, but i will try,
i promise. In the meantime, i always try to test the newest mm patches,
and i have to s
Richard Purdie writes:
> Can you have a look at the differences between the defconfigs for
> 2.6.20 and 2.6.21-rc1?
this is probably the relevant part:
--- config-2.6.20 2007-02-04 12:09:28.0 -0800
+++ config-2.6.21-rc1 2007-02-21 08:37:53.0 -0800
@@ -1270,16 +1302,25 @@
On Thu, 22 Feb 2007, Ingo Molnar wrote:
>
> * Davide Libenzi wrote:
>
> > On Wed, 21 Feb 2007, Ingo Molnar wrote:
> >
> > > From: Ingo Molnar <[EMAIL PROTECTED]>
> > >
> > > add the move_user_context() method to move the user-space
> > > context of one kernel thread to another kernel thread.
On Wednesday 21 February 2007 21:05, Michael K. Edwards wrote:
> On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote:
> > Related to that... Though a parser generated by Bison and a tokenizer
> > generated by Flex both contain large chunks of GPL'd code, their
> > inclusion in the source file that i
On 2/22/07, D. Hazelton <[EMAIL PROTECTED]> wrote:
" We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software."
--IE: Once you release the code under the GPL, it becomes the *
Hi Jörn,
I have been thinking about the problem that you describe, and,
definitively, DualFS does not have that problem. I could be wrong, but,
I actually believe that the GC implemented by DualFS is deadlock-free.
The key is the design of the log-structured file system used by DualFS for
the
Richard Purdie <[EMAIL PROTECTED]> writes:
> If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1
> with that option disabled?
i've disabled FB_RADEON_BACKLIGHT (FB_BACKLIGHT also got deselected)
and i managed to boot into 2.6.21-rc1 and have a working backlight.
--alex--
--
|
The first part of this patch summarizes the patches of the
previous days, namely:
- Add dynamic addition/removal of adapters
(with spiffy error reporting)
- Implement the uevent interface using Sylvain's generic function
- Base fake root device on device instead of of_device
The first part will
This is the aforementioned whitespace fix which applies on top of
part 1/2.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ibmebus.c | 126 +-
include/asm-powerpc/ibmebus.h | 42 +++---
diff -urp b/arch/powerpc/kern
Hi David and Robin,
Thank you for your reply.
Robin Holt wrote:
> On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
>
>>Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
>>
>>>Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
>>>core dumping.
>>
>>No, it doesn't.
Neil Brown wrote:
> On Friday February 16, [EMAIL PROTECTED] wrote:
>
>> I was wondering if the block layer has been changed into a more serialized
>> manner yet? I've been trying to google this, but so far no luck. I know there
>> was some talk about removing the stack based approach, but I can
Hi Greg,
On Wed, Feb 21, 2007 at 09:34:45AM -0800, Greg KH wrote:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazmt??:
> > > Responses should be made by Friday February 23 00:00 UTC. Anything
> > > received after that
Alan wrote:
- Add a driver for motherboard ACPI method devices
- Link it after normal drivers so ACPI is not preferred
- Hook the AMD driver to prefer ACPI for the Nvidia devices if ACPI is
active
- While we are at it fix up the simplex clear the AMD driver.
Depends upon the set_mode -> do_set_m
Russell King wrote:
Plainly, %ebx changed across the call to serial_in() at c01c0f7b.
First thing to notice is this violates the C code - "up" can not
change.
Now let's look at serial_in:
c01bfa70: 55 push %ebp
c01bfa71: 89 e5 mov%esp,%
On Thu, Feb 22, 2007 at 12:34:17PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 11:04:40 +0900 (JST)),
> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> says:
>
> > In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 04:12:04 +0900), OGAW
On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote:
Actually, on re-reading the GPL, I see exactly why they made that pair of
exceptions. Where it's quite evident that a small to mid scale parsers that
could have been written *without* the use of Bison is clearly a
non-derivative work - Bison was
Hi Andrew,
Andrew Morton wrote:
Problem is, it doesn't seem that we'll be merging unionfs any time soon so
we shouldn't be adding slab infrastructure on its behalf. And I'd prefer
not to have to carry slab changes in a filesystem tree.
I think we can merge krealloc without unionfs. I'll whoop
Pekka Enberg wrote:
The ksize exports we can add later if unionfs is to be merged.
Actually, we probably don't need it after the krealloc optimizations. I
think we need a new unionfs patch too... :)
Pekka
-
To unsubscribe from this list: send the line "unsubsc
On Thu, Feb 22, 2007 at 08:18:39AM +0200, Pekka Enberg wrote:
> Pekka Enberg wrote:
> >The ksize exports we can add later if unionfs is to be merged.
>
> Actually, we probably don't need it after the krealloc optimizations. I
> think we need a new unionfs patch too... :)
I'm for it!
Josef "Je
Robert Hancock wrote:
Alan wrote:
Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or
turn on all the ATA debug and shutdown, the code should issue a cache
flush followed by a standbynow1 command for each disk.
Alan
I believe it runs on suspend, but we don't run that code
On Thu, 22 Feb 2007, Pekka Enberg wrote:
> I think we can merge krealloc without unionfs. I'll whoop up a new patch as
> per Christoph's suggestions. I think at least XFS already has its own realloc
> and there might be some other open-coded users. It's not _changing_ the slab
> as much as adding
* Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> [...] As for threadlets, making them kernel threads is not such a good
> design feature, O(1) scheduler or not. You take the full hit of
> kernel task creation, on the spot, for every threadlet that blocks.
> [...]
this is very much not how t
On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> This patch makes writing to shared memory mappings update st_ctime and
> st_mtime as defined by SUSv3:
>
>The st_ctime and st_mtime fields of a file that is mapped with
>MAP_SHARED and PROT_WRITE shall be marke
On Tue, Feb 20, 2007 at 08:43:06AM -0600, Steve Wise wrote:
> On Tue, 2007-02-20 at 01:02 +0100, Adrian Bunk wrote:
> > This patch contains the following possible cleanups:
> > - don't mark static functions in C files as inline - gcc should know
> > best whether inlining makes sense
> > - never c
Thanks Adrian!
Acked-by: Steve Wise <[EMAIL PROTECTED]>
On Wed, 2007-02-21 at 11:52 +0100, Adrian Bunk wrote:
> On Tue, Feb 20, 2007 at 08:43:06AM -0600, Steve Wise wrote:
> > On Tue, 2007-02-20 at 01:02 +0100, Adrian Bunk wrote:
> > > This patch contains the following possible cleanups:
> > > -
Hi Chuck,
On Tue, 20 Feb 2007 10:08:26 -0500, Chuck Ebbert wrote:
> I blacklisted the k8temp driver (and the out-of-tree k8_edac driver
> in Fedora) and the temps were still volatile, so that's not causing
> it. Since then I've upgraded the system BIOS from F.06 to F.27 and
> the problems _may_ ha
Hi Luca,
On Tue, 20 Feb 2007 16:33:56 +0100, Luca Tettamanti wrote:
> Motherboard vendors usually provide tools for $(TheOtherOS) that can
> read from all thermal / fan / voltage / whatever sensors, so I guess
> it's possible to make the ACPI driver and the "raw" one play nice with
> each other[1
Hi Matthew,
On Tue, 20 Feb 2007 15:18:13 +, Matthew Garrett wrote:
> On Sun, Feb 18, 2007 at 06:38:05PM +0100, Jean Delvare wrote:
>
> > ACPI is broken here, not k8temp, so let's fix ACPI instead. ACPI
> > doesn't conflict with only k8temp, but with virtually all hardware
> > monitoring drive
Jean Delvare wrote:
> Can you try to load the i2c-dev driver, then run the following commands
> and report the results:
> $ i2cdetect -l
> For each bus listed:
> $ i2cdetect N
FWIW it's really an ATIIXP chipset, but supposedly PIIX4 compatible:
# i2cdetect -l
i2c-0 smbus SMBus PIIX4 a
On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
>
> >i2c_core
> >i2c_ec
> >i2c_piix4
> >asus_acpi (on a Compaq???)
> >sbs
>
> Something is pulling in asus_acpi as a dependancy. I've never
> figured out
On Wed, 21 Feb 2007 11:03:07 -0500, Chuck Ebbert wrote:
> Jean Delvare wrote:
> > Can you try to load the i2c-dev driver, then run the following commands
> > and report the results:
> > $ i2cdetect -l
> > For each bus listed:
> > $ i2cdetect N
>
> FWIW it's really an ATIIXP chipset, but supposedly
On Wed, Feb 21, 2007 at 05:17:37PM +0100, Jean Delvare wrote:
> On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> > On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
> >
> > > i2c_core
> > > i2c_ec
> > > i2c_piix4
> > > asus_acpi (on a
On Wed, Feb 21, 2007 at 12:37:40PM -0500, Dave Jones wrote:
> On Wed, Feb 21, 2007 at 05:17:37PM +0100, Jean Delvare wrote:
> > On Tue, 20 Feb 2007 14:11:42 -0500, Dave Jones wrote:
> > > On Tue, Feb 20, 2007 at 10:08:26AM -0500, Chuck Ebbert wrote:
> > >
> > > > i2c_core
> > >
The brightness class core does not update the initial status of
the device's brightness at register time. Do it by ourselves
before we register the class device.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Cc: Richard Purdie <[EMAIL PROTECTED]>
---
NOTE: This patch needs an AC
This patch adds in some NCQ blacklist entries taken from the Silicon
Image Windows drivers' .inf files for the 3124 and 3132 controllers.
These entries were marked as ""DisableSataQueueing". Assume these are
in their blacklist for a reason and disable NCQ on these drives.
Signed-off-by: Robert Ha
Recently Tejun wrote a patch to ahci.c to make it raise a HSM violation
if the drive attempted to complete a tag that wasn't outstanding. We could
run into the same problem with sata_nv ADMA. This adds code to raise a HSM
violation error if the controller gives us a notifier tag that isn't
outstan
On Sat, 17 Feb 2007, Andi Kleen wrote:
> That was always its intention. It's not a direct interface to a hypervisor,
> but an somewhat abstracted interface to a "hypervisor driver"
I thought that hypervisor driver was some binary blob that can be directly
accessed via paravirt_ops?
> But you're
Christoph Lameter wrote:
On Sat, 17 Feb 2007, Andi Kleen wrote:
That was always its intention. It's not a direct interface to a hypervisor,
but an somewhat abstracted interface to a "hypervisor driver"
I thought that hypervisor driver was some binary blob that can be directly
accesse
Christoph Lameter wrote:
> And it seems that the hooks are not generic but bound to a particular
> hypervisor. Should the Xen specific stuff not be in the binary blob?
Xen has no "binary blob". It needs guests to cooperate with it by
making hypercalls; all that code is in the Xen implementation
> /*
> + * Temporary hack: zero gs now that we've saved it so that Xen
> + * doesn't try to reload the old value after changing the GDT
> + * during the context switch. This can go away once Xen has
> + * been taught to only reload %gs when it absolutely must.
> + *
Andi Kleen wrote:
> Sorry, but i don't really want that unconditionally in the context switch.
> Adding a paravirt ops for it would be also ugly. Can Xen be fixed?
>
Yes. I'm happy to drop this one.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Wednesday 21 February 2007 21:52, Jeremy Fitzhardinge wrote:
> Add a set of accessors to pack, unpack and modify page table entries
> (at all levels). This allows a paravirt implementation to control the
> contents of pgd/pmd/pte entries. For example, Xen uses this to
> convert the (pseudo-)ph
On 21/2/07 22:10, "Andi Kleen" <[EMAIL PROTECTED]> wrote:
>> /*
>> + * Temporary hack: zero gs now that we've saved it so that Xen
>> + * doesn't try to reload the old value after changing the GDT
>> + * during the context switch. This can go away once Xen has
>> + * been taught to only reloa
Andi Kleen wrote:
> Do you have some lmbench numbers before/after this change?
> iirc at least fork and exit do a lot of pte accesses in various forms.
> If it's measurable it might be needed to patch those for the native case.
>
I don't. I think Rusty ran some numbers and found the pte acces
On Wed, 2007-02-21 at 23:15 +0100, Andi Kleen wrote:
> On Wednesday 21 February 2007 21:52, Jeremy Fitzhardinge wrote:
> > Add a set of accessors to pack, unpack and modify page table entries
> > (at all levels). This allows a paravirt implementation to control the
> > contents of pgd/pmd/pte entr
Andi Kleen wrote:
/*
+* Temporary hack: zero gs now that we've saved it so that Xen
+* doesn't try to reload the old value after changing the GDT
+* during the context switch. This can go away once Xen has
+* been taught to only reload %gs when it absolute
Rusty Russell wrote:
> On Wed, 2007-02-21 at 23:15 +0100, Andi Kleen wrote:
>
>> On Wednesday 21 February 2007 21:52, Jeremy Fitzhardinge wrote:
>>
>>> Add a set of accessors to pack, unpack and modify page table entries
>>> (at all levels). This allows a paravirt implementation to control
Zachary Amsden wrote:
> I agree with that, but especially because this is not even the right
> place to save and clear gs; when userspace uses an LDT based %gs, you
> need to do this all the way back in mmu_context.h before you switch
> the LDT out.
Yeah. This patch was really just to shut my de
On Wed, 21 Feb 2007 12:53:12 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> Some generic early printk & boot console fixups
> (already sent to lkml).
hm, this patch series seems to have gone out of its way to cause problems.
This particular (pathetically changelogged) patch is already i
Andrew Morton wrote:
> hm, this patch series seems to have gone out of its way to cause problems.
>
> This particular (pathetically changelogged) patch is already in my tree,
> only in a later, much more comprehensive form. Similarly the HVC changes
> were already in Rusty's stuff and were suppose
Robert Hancock wrote:
This patch adds in some NCQ blacklist entries taken from the Silicon
Image Windows drivers' .inf files for the 3124 and 3132 controllers.
These entries were marked as ""DisableSataQueueing". Assume these are
in their blacklist for a reason and disable NCQ on these drives.
S
Robert Hancock wrote:
Alan wrote:
- Add a driver for motherboard ACPI method devices
- Link it after normal drivers so ACPI is not preferred
- Hook the AMD driver to prefer ACPI for the Nvidia devices if ACPI is
active
- While we are at it fix up the simplex clear the AMD driver.
Depends upon t
This is a new slab allocator which was motivated by the complexity of the
existing code in mm/slab.c. It attempts to address a variety of concerns
with the existing implementation.
A. Management of object queues
A particular concern was the complex management of the numerous object
queues
* Michael K. Edwards <[EMAIL PROTECTED]> wrote:
> [...] Unless you essentially lock one application thread to each CPU
> core, with a complete understanding of its cache sharing and latency
> relationships to all the other cores, and do your own userspace I/O
> scheduling and dispatching stat
Robert Hancock wrote:
> Robert Hancock wrote:
>> Alan wrote:
>>> Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or
>>> turn on all the ATA debug and shutdown, the code should issue a cache
>>> flush followed by a standbynow1 command for each disk.
>>>
>>> Alan
>>
>> I believe
Christoph Hellwig wrote:
> On Wed, Feb 21, 2007 at 02:13:38PM +0100, Rolf Eike Beer wrote:
> > These functions were inlines before
> > 8b9365d753d9870bb6451504c13570b81923228f. Now EXPORT_SYMBOL() them to
> > allow them to be used in modules again.
>
> Just because they happened to be inlined that
I noticed expensive divides done in try_to_wakeup() and find_busiest_group()
on a bi dual core Opteron machine (total of 4 cores), moderatly loaded (15.000
context switch per second)
oprofile numbers :
CPU: AMD64 processors, speed 2600.05 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles
On Wed, Feb 21, 2007 at 09:57:50PM -0800, H. Peter Anvin wrote:
> Russell King wrote:
>
> >Plainly, %ebx changed across the call to serial_in() at c01c0f7b.
> >First thing to notice is this violates the C code - "up" can not
> >change.
> >Now let's look at serial_in:
> >c01bfa70: 55
> > How about this?
>
> I still don't understand this bug.
>
> > Solves the FUSE deadlock, but not the throttle_vm_writeout() one.
> > I'll try to tackle that one as well.
> >
> > If the per-bdi dirty counter goes below 16, balance_dirty_pages()
> > returns.
> >
> > Does the constant need to tu
* Ulrich Drepper <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
> > in terms of AIO, the best queueing model is i think what the kernel uses
> > internally: freely ordered, with barrier support.
>
> Speaking of AIO, how do you imagine lio_listio is implemented? If
> there is no asynchronous
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> The problem is that the p->last_ran value is not updated after a
> context switch. So a subsequent call to current_sched_time()
> calculates with a stale p->last_ran value, i.e. accounts the full
> time, which the task was scheduled away.
>
> Sig
> On Thu, 22 Feb 2007 08:42:26 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > >
> > > Index: linux/mm/page-writeback.c
> > > ===
> > > --- linux.orig/mm/page-writeback.c2007-02-19 17:32:41.0
> > > +0100
> > > +++
On Thu, 2007-02-22 at 08:46 +0100, Ingo Molnar wrote:
> * Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > The problem is that the p->last_ran value is not updated after a
> > context switch. So a subsequent call to current_sched_time()
> > calculates with a stale p->last_ran value, i.e. account
On Wed, 21 Feb 2007 15:10:39 -0600 "Mike Miller (OS Dev)" <[EMAIL PROTECTED]>
wrote:
> Patch 1/2
>
> This patch changes the way we determine if a logical volume is larger than
> 2TB. The
> original test looked for a total_size of 0. Originally we added 1 to the
> total_size.
> That would make
401 - 500 of 565 matches
Mail list logo
