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
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
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
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
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
.
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
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
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
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
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
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
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:
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
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)
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
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
>
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
/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
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.
> >
> >
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.
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
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
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
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
| |
+ .+
original | . | map kdump kernel here
kernel | .|
| . |
| . .+
+ . . |
| . .|
+ . |
kdump | .|
kernel | . |
| .|
+ |
| |
|
.
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
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
| .|
kernel | . |
| .|
+ |
| |
| |
| |
Thanks,
Hirokazu Takahashi.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
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.
+ 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/
);
-
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/
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
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
-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
34 matches
Mail list logo
