On 11/21/2013 01:35 AM, Tejun Heo wrote:
> Hello,
>
> Sorry about the delay.
>
Oh, No problem, every members time resources are expensive, thank you
for your reply.
> On Fri, Nov 08, 2013 at 04:15:23PM +0800, Chen Gang wrote:
>> After simplify, the related operation, environments and output
Hello,
Sorry about the delay.
On Fri, Nov 08, 2013 at 04:15:23PM +0800, Chen Gang wrote:
> After simplify, the related operation, environments and output are:
>
> [root@gchenlinux tmp]# df -Th | grep cgroup
> tmpfs tmpfs1001M 0 1001M 0%
>
Hello,
Sorry about the delay.
On Fri, Nov 08, 2013 at 04:15:23PM +0800, Chen Gang wrote:
After simplify, the related operation, environments and output are:
[root@gchenlinux tmp]# df -Th | grep cgroup
tmpfs tmpfs1001M 0 1001M 0%
/sys/fs/cgroup
On 11/21/2013 01:35 AM, Tejun Heo wrote:
Hello,
Sorry about the delay.
Oh, No problem, every members time resources are expensive, thank you
for your reply.
On Fri, Nov 08, 2013 at 04:15:23PM +0800, Chen Gang wrote:
After simplify, the related operation, environments and output are:
Hello Maintainers:
On Fedora16 with defconfig for next-20131107 kernel, use latest LTP
(Linux Test Project) version, test_5() in cgroup_regression_test.sh
will be fail. The related LTP output:
<<>>
tag=cgroup stime=1383562810
cmdline=" cgroup_regression_test.sh"
contacts=""
Hello Maintainers:
On Fedora16 with defconfig for next-20131107 kernel, use latest LTP
(Linux Test Project) version, test_5() in cgroup_regression_test.sh
will be fail. The related LTP output:
test_start
tag=cgroup stime=1383562810
cmdline= cgroup_regression_test.sh
contacts=
On 10/15/2013 04:31 PM, Paul E. McKenney wrote:
> On Tue, Oct 15, 2013 at 09:40:40AM +0800, Chen Gang wrote:
>> > Hmm... Can it really work on 1024 CPUs? sorry I don't know. But in fact,
>> > that is not about this patch (it is just one of case which may cause
>> > issues).
>> >
>> > This patch
On Tue, Oct 15, 2013 at 09:40:40AM +0800, Chen Gang wrote:
> On 10/14/2013 07:24 PM, Paul E. McKenney wrote:
> > On Mon, Oct 14, 2013 at 10:22:20AM +0800, Chen Gang wrote:
> >>> - intend to shrink maximized buffer (PAGE_SIZE -> 64, 256 ..) for test.
> >
> > This is a good start! However, you
On Tue, Oct 15, 2013 at 09:40:40AM +0800, Chen Gang wrote:
On 10/14/2013 07:24 PM, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 10:22:20AM +0800, Chen Gang wrote:
- intend to shrink maximized buffer (PAGE_SIZE - 64, 256 ..) for test.
This is a good start! However, you should also
On 10/15/2013 04:31 PM, Paul E. McKenney wrote:
On Tue, Oct 15, 2013 at 09:40:40AM +0800, Chen Gang wrote:
Hmm... Can it really work on 1024 CPUs? sorry I don't know. But in fact,
that is not about this patch (it is just one of case which may cause
issues).
This patch is only about use
On 10/14/2013 07:24 PM, Paul E. McKenney wrote:
> On Mon, Oct 14, 2013 at 10:22:20AM +0800, Chen Gang wrote:
>>> - intend to shrink maximized buffer (PAGE_SIZE -> 64, 256 ..) for test.
>
> This is a good start! However, you should also test the original kernel
> to be sure that it really fails.
On Mon, Oct 14, 2013 at 10:22:20AM +0800, Chen Gang wrote:
> On 10/14/2013 09:41 AM, Chen Gang wrote:
> > On 10/13/2013 07:05 PM, Paul E. McKenney wrote:
> >> On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
> >>> Hello Maintainers:
> >>>
> >>> In srcu_torture_stats(), if cpus are more
On Mon, Oct 14, 2013 at 10:22:20AM +0800, Chen Gang wrote:
On 10/14/2013 09:41 AM, Chen Gang wrote:
On 10/13/2013 07:05 PM, Paul E. McKenney wrote:
On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
Hello Maintainers:
In srcu_torture_stats(), if cpus are more than 1K, the
On 10/14/2013 07:24 PM, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 10:22:20AM +0800, Chen Gang wrote:
- intend to shrink maximized buffer (PAGE_SIZE - 64, 256 ..) for test.
This is a good start! However, you should also test the original kernel
to be sure that it really fails. You
On 10/14/2013 09:41 AM, Chen Gang wrote:
> On 10/13/2013 07:05 PM, Paul E. McKenney wrote:
>> On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
>>> Hello Maintainers:
>>>
>>> In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
>>> not be enough.
>>>
>>> In
On 10/13/2013 07:05 PM, Paul E. McKenney wrote:
> On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
>> Hello Maintainers:
>>
>> In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
>> not be enough.
>>
>> In rcu_torture_printk(), the 'page' maximized size is 4096, it has
On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
> Hello Maintainers:
>
> In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
> not be enough.
>
> In rcu_torture_printk(), the 'page' maximized size is 4096, it has a
> function pointer for printing, which not tell its
On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
Hello Maintainers:
In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
not be enough.
In rcu_torture_printk(), the 'page' maximized size is 4096, it has a
function pointer for printing, which not tell its
On 10/13/2013 07:05 PM, Paul E. McKenney wrote:
On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
Hello Maintainers:
In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
not be enough.
In rcu_torture_printk(), the 'page' maximized size is 4096, it has a
function
On 10/14/2013 09:41 AM, Chen Gang wrote:
On 10/13/2013 07:05 PM, Paul E. McKenney wrote:
On Tue, Oct 08, 2013 at 04:32:53PM +0800, Chen Gang wrote:
Hello Maintainers:
In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
not be enough.
In rcu_torture_printk(), the 'page'
Hello Maintainers:
In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
not be enough.
In rcu_torture_printk(), the 'page' maximized size is 4096, it has a
function pointer for printing, which not tell its maximized length.
Welcome any additional suggestions or completions.
Hello Maintainers:
In srcu_torture_stats(), if cpus are more than 1K, the PAGE_SIZE will
not be enough.
In rcu_torture_printk(), the 'page' maximized size is 4096, it has a
function pointer for printing, which not tell its maximized length.
Welcome any additional suggestions or completions.
Hello Maintainers:
For early_irq_init(), it may be failure (can return an error code), and
for alloc_desc(), also may return 'NULL' when '-ENOMEM'.
But it seems the authors are sure that early_irq_init() are always
success, is it correct ? (or early_irq_init() will never be used ?)
I think, it
Hello Maintainers:
For early_irq_init(), it may be failure (can return an error code), and
for alloc_desc(), also may return 'NULL' when '-ENOMEM'.
But it seems the authors are sure that early_irq_init() are always
success, is it correct ? (or early_irq_init() will never be used ?)
I think, it
On 2013年05月08日 08:50, Li Zefan wrote:
>>> There's a bug in cgroup_unload_subsys() that idr_destroy() should be called
>>> after
>>> >> ss->css_free(). That said, given there's no modular cgroup subsystem
>>> >> using css_id,
>>> >> and the whole css_id thing will be eliminated in 3.11, why
>> There's a bug in cgroup_unload_subsys() that idr_destroy() should be called
>> after
>> ss->css_free(). That said, given there's no modular cgroup subsystem using
>> css_id,
>> and the whole css_id thing will be eliminated in 3.11, why bother fixing it.
>>
>
> I just find it by reading code
On 2013年05月07日 19:01, Li Zefan wrote:
> On 2013/5/7 18:46, Chen Gang wrote:
>> Hello Maintainers:
>>
>> After call get_new_cssid(), I can not find the related free function
>> (it seems free_css_id() is for that, but not used).
>>
>> The memory location is:
>> get_new_cssid() --> kzalloc() for
On 2013/5/7 18:46, Chen Gang wrote:
> Hello Maintainers:
>
> After call get_new_cssid(), I can not find the related free function
> (it seems free_css_id() is for that, but not used).
>
> The memory location is:
> get_new_cssid() --> kzalloc() for 'struct css_id'
> get_new_cssid() -->
Hello Maintainers:
After call get_new_cssid(), I can not find the related free function
(it seems free_css_id() is for that, but not used).
The memory location is:
get_new_cssid() --> kzalloc() for 'struct css_id'
get_new_cssid() --> idr_alloc() for 'ss->idr'
One work flow:
Hello Maintainers:
After call get_new_cssid(), I can not find the related free function
(it seems free_css_id() is for that, but not used).
The memory location is:
get_new_cssid() -- kzalloc() for 'struct css_id'
get_new_cssid() -- idr_alloc() for 'ss-idr'
One work flow:
On 2013/5/7 18:46, Chen Gang wrote:
Hello Maintainers:
After call get_new_cssid(), I can not find the related free function
(it seems free_css_id() is for that, but not used).
The memory location is:
get_new_cssid() -- kzalloc() for 'struct css_id'
get_new_cssid() -- idr_alloc() for
On 2013年05月07日 19:01, Li Zefan wrote:
On 2013/5/7 18:46, Chen Gang wrote:
Hello Maintainers:
After call get_new_cssid(), I can not find the related free function
(it seems free_css_id() is for that, but not used).
The memory location is:
get_new_cssid() -- kzalloc() for 'struct css_id'
There's a bug in cgroup_unload_subsys() that idr_destroy() should be called
after
ss-css_free(). That said, given there's no modular cgroup subsystem using
css_id,
and the whole css_id thing will be eliminated in 3.11, why bother fixing it.
I just find it by reading code (I also want to
On 2013年05月08日 08:50, Li Zefan wrote:
There's a bug in cgroup_unload_subsys() that idr_destroy() should be called
after
ss-css_free(). That said, given there's no modular cgroup subsystem
using css_id,
and the whole css_id thing will be eliminated in 3.11, why bother fixing
it.
On 2013年03月26日 20:27, Frederic Weisbecker wrote:
> 2013/3/26 Chen Gang :
>> > Hello Maintainers:
>> >
>> > compiling with EXTRA_CFLAGS=-W:
>> > make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
>> > make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
>> > set 'arm-linux-gnu-' for cross
2013/3/26 Chen Gang :
> Hello Maintainers:
>
> compiling with EXTRA_CFLAGS=-W:
> make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
> make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
> set 'arm-linux-gnu-' for cross chain prefix
> make V=1 EXTRA_CFLAGS=-W ARCH=arm
>
> it will
oh, sorry, it seems better to let ARM folks know about it.
;-)
On 2013年03月26日 14:36, Chen Gang wrote:
> Hello Maintainers:
>
> compiling with EXTRA_CFLAGS=-W:
> make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
> make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
> set
Hello Maintainers:
compiling with EXTRA_CFLAGS=-W:
make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
set 'arm-linux-gnu-' for cross chain prefix
make V=1 EXTRA_CFLAGS=-W ARCH=arm
it will report:
Hello Maintainers:
compiling with EXTRA_CFLAGS=-W:
make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
set 'arm-linux-gnu-' for cross chain prefix
make V=1 EXTRA_CFLAGS=-W ARCH=arm
it will report:
oh, sorry, it seems better to let ARM folks know about it.
;-)
On 2013年03月26日 14:36, Chen Gang wrote:
Hello Maintainers:
compiling with EXTRA_CFLAGS=-W:
make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
set
2013/3/26 Chen Gang gang.c...@asianux.com:
Hello Maintainers:
compiling with EXTRA_CFLAGS=-W:
make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
set 'arm-linux-gnu-' for cross chain prefix
make V=1 EXTRA_CFLAGS=-W ARCH=arm
On 2013年03月26日 20:27, Frederic Weisbecker wrote:
2013/3/26 Chen Gang gang.c...@asianux.com:
Hello Maintainers:
compiling with EXTRA_CFLAGS=-W:
make V=1 EXTRA_CFLAGS=-W ARCH=arm s3c2410_defconfig
make V=1 EXTRA_CFLAGS=-W ARCH=arm menuconfig
set 'arm-linux-gnu-' for
There is always make gconfig, this is presents a GUI for you. However
keep in mind that compiling your own kernel is never going to be an
idiot proof activity, instead it is something that is going to require a
little bit of knowledge about how the kernel works and how the compile
process works.
i would like to suggest a graphical way to setup and install the
kernel and kernel components, this would make it easier for idiots
like myself to install the kernel with more ease and could solve this
issue of 'bloating'. Making a graphical kernel installer could make it
easier for people to
i would like to suggest a graphical way to setup and install the
kernel and kernel components, this would make it easier for idiots
like myself to install the kernel with more ease and could solve this
issue of 'bloating'. Making a graphical kernel installer could make it
easier for people to
There is always make gconfig, this is presents a GUI for you. However
keep in mind that compiling your own kernel is never going to be an
idiot proof activity, instead it is something that is going to require a
little bit of knowledge about how the kernel works and how the compile
process works.
46 matches
Mail list logo
