Re: [PATCH] Memory Resource Controller Add Boot Option

2008-02-25 Thread Hirokazu Takahashi
Hi, > >>> I'll send out a prototype for comment. > > > > Something like the patch below. The effects of cgroup_disable=foo are: > > > > - foo doesn't show up in /proc/cgroups > > Or we can print out the disable flag, maybe this will be better? > Because we can distinguish from disabled and not

Re: [PATCH] Memory Resource Controller Add Boot Option

2008-02-25 Thread Hirokazu Takahashi
Hi, I'll send out a prototype for comment. Something like the patch below. The effects of cgroup_disable=foo are: - foo doesn't show up in /proc/cgroups Or we can print out the disable flag, maybe this will be better? Because we can distinguish from disabled and not compiled in

Re: [dm-devel] [PATCH 0/2] dm-band: The I/O bandwidth controller: Overview

2008-01-24 Thread Hirokazu Takahashi
to track down which cgroup is the original source. > > do you mean to make this a part of the memory subsystem? I just think if the memory subsystem is in front of us, we don't need to reinvent the wheel. But I don't have a concrete image how the interface between dm-band and the memory subs

Re: [PATCH 0/2] dm-band: The I/O bandwidth controller: Overview

2008-01-24 Thread Hirokazu Takahashi
devices such as information of partitions or LUNs. So some configuration tools may probably be required. Thank you, Hirokazu Takahashi. > Regards, > > Anthony Liguori > > Ryo Tsuruta wrote: > > Hi everyone, > > > > I'm happy to announce that I've implemented a Block

Re: [PATCH 0/2] dm-band: The I/O bandwidth controller: Overview

2008-01-24 Thread Hirokazu Takahashi
or LUNs. So some configuration tools may probably be required. Thank you, Hirokazu Takahashi. Regards, Anthony Liguori Ryo Tsuruta wrote: 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

Re: [dm-devel] [PATCH 0/2] dm-band: The I/O bandwidth controller: Overview

2008-01-24 Thread Hirokazu Takahashi
. But I don't have a concrete image how the interface between dm-band and the memory subsystem should be designed yet. I'd be appreciate if some of the cgroup developers give some ideas about it. Thanks, Hirokazu Takahashi. YAMAMOTO Takashi -- To unsubscribe from this list: send the line

Re: [dm-devel] [PATCH 0/2] dm-band: The I/O bandwidth controller: Overview

2008-01-23 Thread Hirokazu Takahashi
ocumentation. > > I've uploaded it here while we consider ways we might refine the architecture > and > interfaces etc.: > > > http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-add-band-target.patch > > Alasdair > -- > [EMAIL PROTECTED

Re: [dm-devel] [PATCH 0/2] dm-band: The I/O bandwidth controller: Overview

2008-01-23 Thread Hirokazu Takahashi
refine the architecture and interfaces etc.: http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-add-band-target.patch Alasdair -- [EMAIL PROTECTED] Thank you, Hirokazu Takahashi. -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS

2005-09-09 Thread Hirokazu Takahashi
tion is normally > made by specifying another boolean file (contains '0' or '1') > that controls whether that cpuset is one of the selected subsets. What do you think if you make cpusets for sched domain be able to have their siblings, which have the same attribute and share their resources between t

Re: [PATCH 0/5] SUBCPUSETS: a resource control functionality using CPUSETS

2005-09-09 Thread Hirokazu Takahashi
is one of the selected subsets. What do you think if you make cpusets for sched domain be able to have their siblings, which have the same attribute and share their resources between them. I guess it would be simple. Thanks, Hirokazu Takahashi. - To unsubscribe from this list: send the line

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-24 Thread Hirokazu Takahashi
Hi, > The following patch does not use MMX regsiters so that we don't have > to worry about save/restore the FPU/MMX states. > > What do you think? I think __copy_user_zeroing_intel_nocache() should be followed by sfence or mfence instruction to flush the data. - To unsubscribe from this

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-24 Thread Hirokazu Takahashi
Hi, The following patch does not use MMX regsiters so that we don't have to worry about save/restore the FPU/MMX states. What do you think? I think __copy_user_zeroing_intel_nocache() should be followed by sfence or mfence instruction to flush the data. - To unsubscribe from this list:

Re: math_state_restore() question

2005-08-17 Thread Hirokazu Takahashi
Hi, Just take a look at __switch_to(), where __unlazy_fpu() is called. > Hi, > > I have a quick question. > > The math_state_restore() restores the FPU/MMX/XMM states. > However where do we save the previous task's states if it is necessary? > > asmlinkage void math_state_restore(struct

Re: math_state_restore() question

2005-08-17 Thread Hirokazu Takahashi
Hi, Just take a look at __switch_to(), where __unlazy_fpu() is called. Hi, I have a quick question. The math_state_restore() restores the FPU/MMX/XMM states. However where do we save the previous task's states if it is necessary? asmlinkage void math_state_restore(struct pt_regs regs)

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-16 Thread Hirokazu Takahashi
n the stack or so... > > > > oh, really? Does the linux kernel take care of > > SSE save/restore on a task switch? > > not on kernel entry afaik. > However just save the register on the stack and put it back at the > end... I think this have to be done in the pag

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-16 Thread Hirokazu Takahashi
Hi > > > My code does nothing do it. > > > > > > I need a volunteer to implement it. > > > > it's actually not too hard; all you need is to use SSE and not MMX; and > > then just store sse register you're overwriting on the stack or so... > > oh, really? Does the linux kernel take care of >

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-16 Thread Hirokazu Takahashi
Hi My code does nothing do it. I need a volunteer to implement it. it's actually not too hard; all you need is to use SSE and not MMX; and then just store sse register you're overwriting on the stack or so... oh, really? Does the linux kernel take care of SSE save/restore on

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-16 Thread Hirokazu Takahashi
/restore on a task switch? not on kernel entry afaik. However just save the register on the stack and put it back at the end... I think this have to be done in the pagefault handlers. Thanks, Hirokazu Takahashi. - To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-15 Thread Hirokazu Takahashi
Hi, BTW, what are you going to do with the page-faults which may happen during __copy_user_zeroing_nocache()? The current process may be blocked in the handler for a while and get FPU registers polluted. kernel_fpu_begin() won't help the case. This is another issue, though. > > Thanks. > > > >

Re: [RFC] [PATCH] cache pollution aware __copy_from_user_ll()

2005-08-15 Thread Hirokazu Takahashi
Hi, BTW, what are you going to do with the page-faults which may happen during __copy_user_zeroing_nocache()? The current process may be blocked in the handler for a while and get FPU registers polluted. kernel_fpu_begin() won't help the case. This is another issue, though. Thanks.

Re: 2.6.13-rc3-mm1 (ckrm)

2005-07-18 Thread Hirokazu Takahashi
ly, it might make sense to use CKRM to manage resources on > a per-sched domain basis, and to integrate the resource tracking > of CKRM with the resource tracking needs of system accounting. >From a standpoint of the users, CKRM and CPUSETS should be managed seamlessly through the same inter

Re: 2.6.13-rc3-mm1 (ckrm)

2005-07-18 Thread Hirokazu Takahashi
the resource tracking of CKRM with the resource tracking needs of system accounting. From a standpoint of the users, CKRM and CPUSETS should be managed seamlessly through the same interface though I'm not sure whether your idea is the best yet. Thanks, Hirokazu Takahashi. - To unsubscribe from

Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

2005-02-04 Thread Hirokazu Takahashi
tectures. I prefer it rather than linking the kernel for each system. > Most of this just results in easier management between the pieces. > Which is a good thing. However at the moment I don't think it > simplifies any of the core problems. I still need to reserve > a large hunk o

Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

2005-02-04 Thread Hirokazu Takahashi
that improve this I don't actually care right now. ok. Eric Thanks, Hirokazu Takahashi. - 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

Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

2005-02-03 Thread Hirokazu Takahashi
| | + .+ original | . | map kdump kernel here kernel | .| | . | | . .+ + . . | | . .| + . | kdump | .| kernel | . | | .| + | | | |

Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

2005-02-03 Thread Hirokazu Takahashi
. I see, that makes sense. But I'm not sure yet that it's safe to access the top of 640MB. I wonder how kmalloc(GFP_DMA) works in a kdump kernel. Thanks, Hirokazu Takahashi. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED

Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

2005-02-03 Thread Hirokazu Takahashi
to access the top of 640MB. I wonder how kmalloc(GFP_DMA) works in a kdump kernel. Thanks, Hirokazu Takahashi. - 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

Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

2005-02-03 Thread Hirokazu Takahashi
| .| kernel | . | | .| + | | | | | | | Thanks, Hirokazu Takahashi. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

2005-02-02 Thread Hirokazu Takahashi
booted with modified memmap (User gets > backup region information from /proc/iomem) and capture tool can > extract backup area information from elf headers as stored by first > kernel. > > Could you please elaborate a little more on what aspect of your view > differs from the above.

Re: Hugepages demand paging V2 [3/8]: simple numa compatible allocator

2005-02-02 Thread Hirokazu Takahashi
+ if (z) { > page = list_entry(hugepage_freelists[nid].next, > struct page, lru); > list_del(>lru); > > - Thanks, Hirokazu Takahashi. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Hugepages demand paging V2 [3/8]: simple numa compatible allocator

2005-02-02 Thread Hirokazu Takahashi
); - Thanks, Hirokazu Takahashi. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [Fastboot] [PATCH] Reserving backup region for kexec based crashdumps.

2005-02-02 Thread Hirokazu Takahashi
region information from /proc/iomem) and capture tool can extract backup area information from elf headers as stored by first kernel. Could you please elaborate a little more on what aspect of your view differs from the above. Thanks Vivek Thaks, Hirokazu Takahashi. - To unsubscribe from

Re: Hugepages demand paging V2 [1/8]: hugetlb fault handler

2005-01-18 Thread Hirokazu Takahashi
gt; - goto out; > - > if (inode->i_size < len) > inode->i_size = len; > out: hugetlbfs_file_mmap() may fail with a weird error, as it returns uninitialized variable "ret". Thanks. Hirokazu Takahashi. - To unsubscribe from this lis

Re: Hugepages demand paging V2 [1/8]: hugetlb fault handler

2005-01-18 Thread Hirokazu Takahashi
-i_size = len; out: hugetlbfs_file_mmap() may fail with a weird error, as it returns uninitialized variable ret. Thanks. Hirokazu Takahashi. - 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