On Wed, 2008-01-23 at 01:46 -0600, Paul Jackson wrote:
Huang wrote:
This patchset has been merged into Linux 2.6.24.
Excellent.
Unfortunately, the new EFI support patches do not use EFI memory map for
system boot up ... So, I think the resolution for your problem is the
struct
Your patches just shove another extra into the existing code base
without doing any consolidation work and without any consideration of
problems we need to urgently solve in this area.
I fixed the problems in CPA I was aware of -- I'm not aware of
any other current ones (urgent or not).
Hi Christoph,
On Jan 23, 2008 1:18 AM, Christoph Lameter [EMAIL PROTECTED] wrote:
My patch is useless (fascinating history of the changelog there through).
fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that
alloc_pages_node() will try to allocate on the current node but
The function __cpufreq_set_policy in file drivers/cpufreq/cpufreq.c
has a very obvious error:
if (policy-min data-min policy-min policy-max) {
ret = -EINVAL;
goto error_out;
}
This condtion statement is wrong because it returns -EINVAL only if
On Wed, Jan 23, Pekka Enberg wrote:
Hi Christoph,
On Jan 23, 2008 1:18 AM, Christoph Lameter [EMAIL PROTECTED] wrote:
My patch is useless (fascinating history of the changelog there through).
fallback_alloc calls kmem_getpages without GFP_THISNODE. This means that
alloc_pages_node()
On Wed, 23 Jan 2008, Dave Young wrote:
On Jan 23, 2008 3:41 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008, David Miller wrote:
From: Dave Young [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 09:44:30 +0800
On Jan 22, 2008 6:47 PM, Ilpo Järvinen [EMAIL PROTECTED]
David Chinner [EMAIL PROTECTED] writes:
On Tue, Jan 22, 2008 at 10:49:15AM +0100, Jens Axboe wrote:
Hi,
Today io contexts are per-process and define the (surprise) io context
of that process. In some situations it would be handy if several
processes share an IO context.
I think
On Wed, 2008-01-23 at 02:21 +0300, Anton Salikhmetov wrote:
+static void vma_wrprotect_pmd_range(struct vm_area_struct *vma, pmd_t *pmd,
+ unsigned long start, unsigned long end)
+{
+ while (start end) {
+ spinlock_t *ptl;
+ pte_t *pte =
Karl Kiniger [EMAIL PROTECTED] writes:
FYI,
on http://www.feise.com/~jfeise/Downloads/linux-abi/
a patch named linux-abi-2.6.22.3_3.diff.bz2 can be found.
So just add a reversed version of my binfmt_elf patch to that.
If people need to apply a patch anyways it doesn't make much
[PATCH] x86_64: remove duplicated line about x86_bios_cpu_apicid_early_ptr
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 2643a8f..b587166 100644
--- a/arch/x86/kernel/setup_64.c
+++ b/arch/x86/kernel/setup_64.c
@@ -349,7
On Wed, 2008-01-23 at 09:47 +0100, Peter Zijlstra wrote:
On Wed, 2008-01-23 at 02:21 +0300, Anton Salikhmetov wrote:
+static void vma_wrprotect(struct vm_area_struct *vma)
+{
+ unsigned long addr = vma-vm_start;
+ pgd_t *pgd = pgd_offset(vma-vm_mm, addr);
+
+ while (addr
Ingo Molnar [EMAIL PROTECTED] writes:
that is (yet another) major misconception on your part. Drivers are an
easy to blame target (i guess because there's no one out there to defend
a vague drivers accusation), and they are not the problem here _at
all_.
In this case the problem is that
On Jan 23 2008 12:18, Bryan Wu wrote:
[PATCH] procfs: constify function pointer tables
---
arch/alpha/kernel/setup.c |2 +-
arch/blackfin/kernel/setup.c |2 +-
[...]
diff --git a/arch/alpha/kernel/setup.c b/arch/alpha/kernel/setup.c
index bd5e68c..823f18e 100644
---
Allow to limit the network bandwidth for specific process containers (cgroups)
imposing additional delays in the sockets' sendmsg()/recvmsg() calls made by
those processes that exceed the limits defined in the control group filesystem.
Example:
# mkdir /dev/cgroup
# mount -t cgroup -onet net
Since GFP_DMA32 is not considered a valid flag, vmalloc_32 and
SLAB are incompatible in kernel 2.6.23.9 (and probably later ones).
It might be as simple as adding GFP_DMA32 everywhere where
GFP_DMA is used in mm/slab.c, but I don't dare do it. I personally
switched to SLUB.
[PATCH] x86_64: should use array directly for early_ptr
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
--- a/arch/x86/kernel/setup_64.c2008-01-23 01:21:06.0 -0800
+++ b/arch/x86/kernel/setup_64.c2008-01-23 01:21:24.0 -0800
@@ -344,10 +344,10 @@
#ifdef CONFIG_SMP
* Andrea Righi [EMAIL PROTECTED] [2008-01-23 10:09:28]:
Allow to limit the network bandwidth for specific process containers (cgroups)
imposing additional delays in the sockets' sendmsg()/recvmsg() calls made by
those processes that exceed the limits defined in the control group
filesystem.
I think it would be more logical to move this patch forward, before
the two patches which this document is actually describing.
Add a document, which describes how the POSIX requirements on updating
memory-mapped file times are addressed in Linux.
Signed-off-by: Anton Salikhmetov [EMAIL
Arjan van de Ven [EMAIL PROTECTED] writes:
This patch adds a test module for the DEBUG_RODATA config
option to make sure change_page_attr() did indeed make
const data read only.
The only that this does that is not done pretty much equivalently
by pageattr-test.c (it just checks G instead of
Greg KH [EMAIL PROTECTED] 22.01.08 23:15
On Tue, Jan 22, 2008 at 01:31:21PM +, Jan Beulich wrote:
.. as all consumers of it don't require it to be modifiable.
Unfortunately, due to the two-level constifications, this required
touching quite many files, not all of which I am able to test
Robert Hancock wrote:
Kuan Luo wrote:
Robert hancock wrote:
What problem does this resolve? I tested it against the cache
flush/NCQ write switching problem we've been trying to solve, and it
doesn't look like it fixes that one - if I apply this patch and then
remove the udelay(20) in
On Wed, 2008-01-23 at 09:47 +0100, Peter Zijlstra wrote:
On Wed, 2008-01-23 at 02:21 +0300, Anton Salikhmetov wrote:
+static void vma_wrprotect(struct vm_area_struct *vma)
+{
+ unsigned long addr = vma-vm_start;
+ pgd_t *pgd = pgd_offset(vma-vm_mm, addr);
+
+ while (addr
Loïc Grenié [EMAIL PROTECTED] writes:
Since GFP_DMA32 is not considered a valid flag, vmalloc_32 and
SLAB are incompatible in kernel 2.6.23.9 (and probably later ones).
It might be as simple as adding GFP_DMA32 everywhere where
GFP_DMA is used in mm/slab.c, but I don't dare do it.
Force file times update at the next write reference after
calling the msync() system call with the MS_ASYNC flag.
Signed-off-by: Anton Salikhmetov [EMAIL PROTECTED]
---
mm/msync.c | 92 +--
1 files changed, 82 insertions(+), 10
On Friday 18 January 2008 13:16:43 Glauber de Oliveira Costa wrote:
It should depend on CONFIG_LGUEST, not CONFIG_LGUEST_GUEST
Actually, it needs both. Some parts are guest, some are host.
Cheers,
Rusty.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Also, it still doesn't make sense to me why we'd not need to walk the
rmap, it is all the same file after all.
It's the same file, but not the same memory map. It basically depends
on how you define msync:
a) sync _file_ on region defined by this mmap/start/end-address
b) sync
An approach that we've been experimenting with at Google is much simpler:
- add a network class id subsystem, that lets you associated an id
with each cgroup
- propagate this id to sockets created by that cgroup, and from there
to packets sent/received on that socket
- add a new traffic filter
Jike Song wrote:
Hello Jeff,
The pci-skeleton.c has several problems with compilation, such as missing args
when calling synchronize_irq(). Fix it.
Signed-off-by: Jike Song [EMAIL PROTECTED]
---
drivers/net/pci-skeleton.c | 49 ++-
1 files changed, 25
__scsi_device_lookup and __scsi_device_lookup_by_target do not
check for the sdev_state and hence return scsi_devices with
sdev_state set to SDEV_DEL also. It has the following side effects.
We can have two scsi_devices with the same HBTL queued in
the scsi_host-__devices/scsi_target-devices
23 Jan 2008 10:35:28 +0100, Andi Kleen [EMAIL PROTECTED]:
Loïc Grenié [EMAIL PROTECTED] writes:
Since GFP_DMA32 is not considered a valid flag, vmalloc_32 and
SLAB are incompatible in kernel 2.6.23.9 (and probably later ones).
It might be as simple as adding GFP_DMA32 everywhere
vmalloc_32 is using __vmalloc. I am much too ignorant to try and change
anything in mm/*.[ch]. If vmalloc_32 is incompatible with sl[aou]b,
should'nt
it be either modified or removed ?
vmalloc does not use sl[aou]b for the data pages. That is why it can
support GFP_DMA32 (or even
Hi,
Currently you must be root to set idle io prio class on a process. This
is due to the fact that the idle class is implemented as a true idle
class, meaning that it will not make progress if someone else is
requesting disk access. Unfortunately this means that it opens DOS
opportunities by
On 1/23/08, Jeff Garzik [EMAIL PROTECTED] wrote:
ACK but git-am (everybody's patch import tool) says the patch is corrupted
Hi Jeff,
Thank you very much for your acknowledgement! This is my first patch
for Linux kernel, sorry for the corruption. I'll resend it ASAP.
Regards,
Jike
--
To
On Sat, 22 Dec 2007 00:11:12 +0300, Vitaly Bordug wrote:
On Fri, 21 Dec 2007 20:36:28 +0100
Jochen Friedrich wrote:
Using the port of 2.4 code from Vitaly Bordug
[EMAIL PROTECTED] and the actual algorithm used by the i2c
driver of the DBox code on cvs.tuxboc.org from Tmbinc, Gillem
On (23/01/08 11:04), KOSAKI Motohiro didst pronounce:
Hi mel
Hi
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be
On (23/01/08 11:04), KOSAKI Motohiro didst pronounce:
Hi mel
Hi
A fix[1] was merged to the x86.git tree that allowed NUMA kernels to boot
on normal x86 machines (and not just NUMA-Q, Summit etc.). I took a look
at the restrictions on setting NUMA on x86 to see if they could be
Christoph Lameter wrote:
Ahhh. Good to hear. But we will still end in a situation where only
the remote ptes point to the page. Maybe the remote instance will dirty
the page at that point?
When the spte is dropped, its dirty bit is transferred to the page.
sharing code, and for you
On (22/01/08 14:33), Andi Kleen didst pronounce:
Without SRAT support, a compile-error occurs because ACPI table parsing
functions are only available in x86-64. This patch also adds no-op stubs
and prints a warning message. What likely needs to be done is sharing
the table parsing
Hi Jochen,
Sorry for the late answer.
On Thu, 3 Jan 2008 10:41:21 +1100, Stephen Rothwell wrote:
Hi Jochen,
Just a few trivial things.
On Wed, 02 Jan 2008 20:52:00 +0100 Jochen Friedrich [EMAIL PROTECTED] wrote:
+++ b/drivers/i2c/busses/i2c-cpm.c
+
+static irqreturn_t
2008/1/23, Miklos Szeredi [EMAIL PROTECTED]:
I think it would be more logical to move this patch forward, before
the two patches which this document is actually describing.
Add a document, which describes how the POSIX requirements on updating
memory-mapped file times are addressed in
On Jan 23, 2008 5:06 PM, Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jan 23 2008 12:18, Bryan Wu wrote:
[PATCH] procfs: constify function pointer tables
---
arch/alpha/kernel/setup.c |2 +-
arch/blackfin/kernel/setup.c |2 +-
[...]
diff --git a/arch/alpha/kernel/setup.c
i386 already has srat parsing code (just written in a horrible hackish
way); but it exists arch/x86/kernel/srat_32.c
Yes, I spotted that. Enabling it required a Kconfig change
does it? I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
already used that. At least that was the case
those errors apears only when I use the harddrives with
the sii controller and only when I make operation between
the onboard sata and the sii sata controller, operations between
ide and drives that are on sii works perfectly...
On Tue, 22 Jan 2008, Jeff Garzik wrote:
Dan Nica wrote:
hello
On (23/01/08 08:58), Olaf Hering didst pronounce:
On Tue, Jan 22, Christoph Lameter wrote:
0xc00fe018 is in setup_cpu_cache
(/home/olaf/kernel/git/linux-2.6-numa/mm/slab.c:2111).
2106BUG_ON(!cachep-nodelists[node]);
2107
On Wed, Jan 23, 2008 at 12:27:57PM +0200, Avi Kivity wrote:
The approach with the export notifier is page based not based on the
mm_struct. We only need a single page count for a page that is exported to
a number of remote instances of linux. The page count is dropped when all
the remote
I've already written in the cover letter that functional tests passed
successfully.
debian:~/times# ./times /mnt/file
begin 1201084493 1201084493 1201084281
write 1201084494 1201084494 1201084281
mmap1201084494 1201084494 1201084495
b 1201084496
On Tue, 22 Jan 2008 23:27:27 +0300
Alexey Dobriyan [EMAIL PROTECTED] wrote:
/proc/sys part of sysctl code runs without BKL held, so BKL during
sysctl(2) is useless. Remove misleading comment and protection around
coredumping code -- kernel.core_pattern can be written without BKL.
Just one more try
Ubuntu x86_64 gcc-4.2
WARNING: vmlinux.o(.text.head+0xe4): Section mismatch: reference to
.init.data.2:trampoline_level4_pgt (between 'ident_complete' and
'secondary_startup_64')
WARNING: vmlinux.o(.text.head+0xeb): Section mismatch: reference to
On (23/01/08 11:45), Andi Kleen didst pronounce:
i386 already has srat parsing code (just written in a horrible hackish
way); but it exists arch/x86/kernel/srat_32.c
Yes, I spotted that. Enabling it required a Kconfig change
does it?
hmm, just a removal of (X86_SUMMIT ||
On Wed, 23 Jan 2008, Ilpo Järvinen wrote:
On Wed, 23 Jan 2008, Dave Young wrote:
On Jan 23, 2008 3:41 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote:
On Tue, 22 Jan 2008, David Miller wrote:
From: Dave Young [EMAIL PROTECTED]
Date: Wed, 23 Jan 2008 09:44:30 +0800
On Jan
Alan Cox [EMAIL PROTECTED] writes:
There are cases that updating the corepath name and dumping a core at the
same moment can result in the wrong thing being exec()'d or a file being
opened which is a mix of the old and new name and could go anywhere.
I see two variants on your patch that
I was pretty sure that a !NUMAQ i386 CONFIG_NUMA build
already used that.
Presumably a GENERICARCH configuration
GENERICARCH includes SUMMIT so yes.
At least that was the case when I last looked. If that
has changed it must have bitrotted recently.
I don't think it has bit-rotted. I
Anyways from your earlier comments it sounds like you're trying to add SRAT
parsing to CONFIG_NUMAQ. Since that's redundant with the old implementation
it doesn't sound like a very useful thing to do.
But the patch is applied already i think. Well I'm sure it passed
checkpatch.pl at least.
Ah, OK, this is becuase mmap doesn't actually set up the page tables
by default. Try adding MAP_POPULATE to the flags.
Here's an updated version of the program, with an added a '-r' option,
that performs a read access on the mapping before doing the write
(basically equivalent to
On Wed, 2008-01-23 at 09:46 +0100, Andi Kleen wrote:
Harvey Harrison [EMAIL PROTECTED] writes:
nx_enabled can only be set to non-zero when CONFIG_X86_PAE is
set. The only use not currently inside a CONFIG_X86_PAE block
is the definition, the declaration and a conditional unlikely
test
Hi Jean,
Do you have an updated patch addressing Stephen's comment?
Note: you'd rather send updates of this patch to the i2c list rather
than LKML.
I'm currently looking at that last patches from Jon and try to make this
driver fit in there (+ the class override stuff).
Note: will do. I
On Jan 23 2008 18:41, Bryan Wu wrote:
Oh, this patch does not touch all, following is the missing list:
---
[...]
arch/ia64/hp/common/sba_iommu.c:static struct seq_operations ioc_seq_ops = {
arch/ia64/kernel/perfmon.c:struct seq_operations pfm_seq_ops = {
arch/ia64/kernel/setup.c:struct
On (23/01/08 12:15), Andi Kleen didst pronounce:
Anyways from your earlier comments it sounds like you're trying to add SRAT
parsing to CONFIG_NUMAQ. Since that's redundant with the old implementation
it doesn't sound like a very useful thing to do.
No, that would not be useful at all as
- Original Message
From: Alasdair G Kergon [EMAIL PROTECTED]
To: Martin Knoblauch [EMAIL PROTECTED]
Cc: Linus Torvalds [EMAIL PROTECTED]; Mel Gorman [EMAIL PROTECTED];
Fengguang Wu [EMAIL PROTECTED]; Mike Snitzer [EMAIL PROTECTED]; Peter
Zijlstra [EMAIL PROTECTED]; [EMAIL
On Wed, Jan 23, 2008 at 11:52:13AM +0100, Alejandro Riveira Fernández wrote:
Just one more try
Ubuntu x86_64 gcc-4.2
WARNING: vmlinux.o(.text.head+0xe4): Section mismatch: reference to
.init.data.2:trampoline_level4_pgt (between 'ident_complete' and
'secondary_startup_64')
WARNING:
On 23 Jan 2008 12:09:05 +0100
Andi Kleen [EMAIL PROTECTED] wrote:
Alan Cox [EMAIL PROTECTED] writes:
There are cases that updating the corepath name and dumping a core at the
same moment can result in the wrong thing being exec()'d or a file being
opened which is a mix of the old and
Hi Christoph,
On Tue, Jan 22, 2008 at 02:53:12PM -0800, Christoph Lameter wrote:
On Tue, 22 Jan 2008, Andrea Arcangeli wrote:
First it makes me optimistic this can be merged sooner than later to
see a second brand new implementation of this ;).
Brand new? Well this is borrowing as much
On Tue, 22 Jan 2008 17:52:43 +0100
Marc Pignat [EMAIL PROTECTED] wrote:
Hi!
I removed [EMAIL PROTECTED] from cc, it is a
subscriber-only list.
Right. Does that mean I shouldn't Cc it on patches?
On Tuesday 22 January 2008, Haavard Skinnemoen wrote:
From: Chip Coldwell [EMAIL PROTECTED]
Defined as a NOP on AVR32 as per the asm-generic implementation.
This keeps /dev/mem happy.
Signed-Off-By: Ben Nizette [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc8-mm1/include/asm-avr32/io.h
===
---
Some parts of this function use 'page', some 'pte'. As such, an AVR32
-mm build fails with an undefined reference to 'page'.
Signed-Off-By: Ben Nizette [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc8-mm1/include/asm-avr32/pgalloc.h
On Wed, Jan 23, 2008 at 04:52:47AM -0600, Robin Holt wrote:
But 100 callouts holding spinlocks will not work for our implementation
and even if the callouts are made with spinlocks released, we would very
strongly prefer a single callout which messages the range to the other
side.
But you
On Wed, Jan 23, Mel Gorman wrote:
Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of the
following patch against 2.6.24-rc8 please? It contains the debug information
that helped me figure out what was going wrong on the PPC64 machine here,
the revert and the !l3 checks
On Jan 23, 2008 7:25 PM, Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jan 23 2008 18:41, Bryan Wu wrote:
Oh, this patch does not touch all, following is the missing list:
---
[...]
arch/ia64/hp/common/sba_iommu.c:static struct seq_operations ioc_seq_ops = {
arch/ia64/kernel/perfmon.c:struct
On Wed, 23 Jan 2008 22:57:34 +1100
Ben Nizette [EMAIL PROTECTED] wrote:
Some parts of this function use 'page', some 'pte'. As such, an AVR32
-mm build fails with an undefined reference to 'page'.
Signed-Off-By: Ben Nizette [EMAIL PROTECTED]
---
Index:
2008/1/23, Miklos Szeredi [EMAIL PROTECTED]:
Ah, OK, this is becuase mmap doesn't actually set up the page tables
by default. Try adding MAP_POPULATE to the flags.
Here's an updated version of the program, with an added a '-r' option,
that performs a read access on the mapping before
Hi!
On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
On Tue, 22 Jan 2008 17:52:43 +0100
Marc Pignat [EMAIL PROTECTED] wrote:
Hi!
I removed [EMAIL PROTECTED] from cc, it is a
subscriber-only list.
Right. Does that mean I shouldn't Cc it on patches?
extract from the
Christoph, Maybe you can clear one thing up. Was this proposal an
addition to or replacement of Andrea's? I assumed an addition. I am
going to try to restrict my responses to ones appropriate for that
assumption.
The remote instance is like a secondary TLB what you're doing in your
code is
Why don't you stick to mm+va and use get_user_pages and let the VM do
the swapins etc...?
Our concern is also with memory protections for the physical page.
Additionally, we need to support exporting of memory in a VM_PFNMAP
address ranges (specifically, memory mapped using sgi_fetchop,
On Wednesday 23 January 2008, Benjamin Herrenschmidt wrote:
On Wed, 2008-01-23 at 01:58 +0100, Bartlomiej Zolnierkiewicz wrote:
I'm more worried about breaking automatic build checking (make randconfig)
than a few extra bytes so if you remove all #ifdefs you'll have to either
make
The log is pretty messy, any chance you could reshuffle the gazillions
of fixup patches into the few feature patches to give a proper readable
history in git?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
On Wed, 23 Jan 2008 13:30:32 +0100
Marc Pignat [EMAIL PROTECTED] wrote:
On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
Right. Does that mean I shouldn't Cc it on patches?
extract from the linux-arm-kernel 'Mailing List Etiquette':
10. Cross-posting between linux-arm*
On Tue 2008-01-15 17:49:36, Andrea Righi wrote:
Allow to limit the I/O bandwidth for specific uid(s) or gid(s) imposing
additional delays on those processes that exceed the limits defined in a
configfs tree.
Examples:
Limit the I/O bandwidth for user www-data (UID 33) to 4MB/s:
[EMAIL
On Fri 2008-01-18 01:27:06, H. Peter Anvin wrote:
Kyle McMartin wrote:
On Fri, Jan 18, 2008 at 06:53:53AM +0100, Andi Kleen
wrote:
One problem that we had in the past is that some
simulators
only implement the absolutely minimum feature set and
you
might have well broken one of these
On Wed, Jan 23, Olaf Hering wrote:
On Wed, Jan 23, Mel Gorman wrote:
Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of
the
following patch against 2.6.24-rc8 please? It contains the debug information
that helped me figure out what was going wrong on the PPC64
Hi,
Jumping in here, looks like this could develop into a direction useful
for Xen.
Background: Xen has a mechanism called grant tables for page sharing.
Guest #1 can issue a grant for another guest #2, which in turn then
can use that grant to map the page owned by guest #1 into its address
2008/1/23, Peter Zijlstra [EMAIL PROTECTED]:
On Wed, 2008-01-23 at 02:21 +0300, Anton Salikhmetov wrote:
+static void vma_wrprotect_pmd_range(struct vm_area_struct *vma, pmd_t *pmd,
+ unsigned long start, unsigned long end)
+{
+ while (start end) {
+
Hi everyone,
I'm happy to announce that I've implemented a Block I/O bandwidth controller.
The controller is designed to be of use in a cgroup or virtual machine
environment. The current approach is that the controller is implemented as
a device-mapper driver.
What's dm-band all about?
On Wed, Jan 23, 2008 at 04:34:12PM +1100, David Chinner wrote:
I've had suspicions of a race in the remount-ro code in
do_remount_sb() w.r.t to the fs_may_remount_ro() check. That is, we
do an unlocked check to see if we can remount readonly and then fail
to check again once we've locked the
Here is the patch of dm-band.
Based on 2.6.23.14
Signed-off-by: Ryo Tsuruta [EMAIL PROTECTED]
Signed-off-by: Hirokazu Takahashi [EMAIL PROTECTED]
diff -uprN linux-2.6.23.14.orig/drivers/md/Kconfig
linux-2.6.23.14/drivers/md/Kconfig
--- linux-2.6.23.14.orig/drivers/md/Kconfig 2008-01-15
Here is the document of dm-band.
Based on 2.6.23.14
Signed-off-by: Ryo Tsuruta [EMAIL PROTECTED]
Signed-off-by: Hirokazu Takahashi [EMAIL PROTECTED]
diff -uprN linux-2.6.23.14.orig/Documentation/device-mapper/band.txt
linux-2.6.23.14/Documentation/device-mapper/band.txt
---
Hallo Jochen,
On Wed, 23 Jan 2008 12:23:58 +0100, Jochen Friedrich wrote:
Hi Jean,
Do you have an updated patch addressing Stephen's comment?
Note: you'd rather send updates of this patch to the i2c list rather
than LKML.
I'm currently looking at that last patches from Jon and try
2008/1/23, Miklos Szeredi [EMAIL PROTECTED]:
Also, it still doesn't make sense to me why we'd not need to walk the
rmap, it is all the same file after all.
It's the same file, but not the same memory map. It basically depends
on how you define msync:
a) sync _file_ on region
Hi!
On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
On Wed, 23 Jan 2008 13:30:32 +0100
Marc Pignat [EMAIL PROTECTED] wrote:
On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
...
Ok, but then any power of two larger than the cache line size should be
fine, assuming kmalloc()
On Wed, Jan 23, 2008 at 01:51:23PM +0100, Gerd Hoffmann wrote:
Jumping in here, looks like this could develop into a direction useful
for Xen.
Background: Xen has a mechanism called grant tables for page sharing.
Guest #1 can issue a grant for another guest #2, which in turn then
can use
Hi -
On Tue, Jan 22, 2008 at 11:17:40PM -0500, Jon Masters wrote:
On Tue, 2008-01-22 at 22:10 -0500, Mathieu Desnoyers wrote:
[...]
Is this an attempt to not set a marker for proprietary modules? [...]
I can't seem to find any discussion about this aspect. If this is the
intent,
On Wed 23-01-08 12:00:02, Nick Piggin wrote:
On Wednesday 23 January 2008 04:10, Jan Kara wrote:
Hi,
as I got no answer for a week, I'm resending this fix for races in
private_list handling. Andrew, do you like them more than the previous
version?
FWIW, I reviewed this, and it
Hi,
I'm not qualified to comment on the code, but here are some suggestions on
config option and comments.
Cheers,
FJP
Ryo Tsuruta wrote:
+config DM_BAND
+ tristate I/O band width control
s/band width/bandwidth/
(it seems to be used correctly elsewhere, but you may want to double-check)
On Wed, 23 Jan 2008 14:18:38 +0100
Marc Pignat [EMAIL PROTECTED] wrote:
On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
Ok, but then any power of two larger than the cache line size should be
fine, assuming kmalloc() returns a properly aligned buffer.
Yes. The memory should be
On (23/01/08 13:14), Olaf Hering didst pronounce:
On Wed, Jan 23, Mel Gorman wrote:
Sorry this is dragging out. Can you post the full dmesg with loglevel=8 of
the
following patch against 2.6.24-rc8 please? It contains the debug information
that helped me figure out what was going wrong
On Wednesday 23 January 2008 12:24:36 Mel Gorman wrote:
On (23/01/08 12:15), Andi Kleen didst pronounce:
Anyways from your earlier comments it sounds like you're trying to add
SRAT parsing to CONFIG_NUMAQ. Since that's redundant with the old
implementation it doesn't sound like a very
On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
On Wed, 23 Jan 2008 14:18:38 +0100
...
GFP_DMA doesn't have anything to do with alignment, AFAIK.
I don't even know if it does something for at91 or avr32, but there is a flag
for dma memory, so we should use it.
...
No, please don't. If
This patch in combination with a partial revert of commit
04231b3002ac53f8a64a7bd142fde3fa4b6808c6 fixes a regression between 2.6.23
and 2.6.24-rc8 where a PPC64 machine with all CPUS on a memoryless node fails
to boot. If approved by the SLAB maintainers, it should be merged for 2.6.24.
With
Miklos, thanks for your program. Its output is given below.
debian:~/miklos# mount | grep mnt
tmpfs on /mnt type tmpfs (rw)
debian:~/miklos# ./miklos /mnt/file
begin 1201089989 1201089989 1201085868
write 1201089990 1201089990 1201085868
mmap1201089990
On Wed, 23 Jan 2008 14:52:55 +0100
Marc Pignat [EMAIL PROTECTED] wrote:
On Wednesday 23 January 2008, Haavard Skinnemoen wrote:
On Wed, 23 Jan 2008 14:18:38 +0100
...
GFP_DMA doesn't have anything to do with alignment, AFAIK.
I don't even know if it does something for at91 or avr32, but
This sounds like a return to the old behavior, where sdevs in SDEV_DEL
were ignored. However, it too had lots of bad effects. We'd have to go
back to the threads over the last 2 years that justified resurrecting
the sdev. Start looking at threads like :
1 - 100 of 968 matches
Mail list logo
