[PATCH] fix up perfmon to build on -mm - Kernel

This is a discussion on [PATCH] fix up perfmon to build on -mm - Kernel ; Here's a patch against my current tree that gets the perfmon code building and hopefully working. Note, it needs the kobject_create_and_register() patch which is in my tree, but I do not think it made it to -mm yet. The next ...

+ Reply to Thread
Page 1 of 6 1 2 3 ... LastLast
Results 1 to 20 of 113

Thread: [PATCH] fix up perfmon to build on -mm

  1. [PATCH] fix up perfmon to build on -mm

    Here's a patch against my current tree that gets the perfmon code
    building and hopefully working.

    Note, it needs the kobject_create_and_register() patch which is in my
    tree, but I do not think it made it to -mm yet. The next -mm cycle
    should have it.

    Also, the sysfs usage in the perfmon code is quite strange and not
    documented at all. Yes, there is a little bit in the documentation
    about what a few of the files do, but there are _way_ more files and
    even directories being created under /sys/kernel/perfmon/ that are not
    documented at all here.

    If you document this stuff, I think I can clean up your sysfs code a
    lot, making things simpler, easier to extend, and easier to understand.
    But as it is, I don't want to break anything as it's totally unknown how
    this stuff is supposed to work...

    Hint, use the Documentation/ABI directory to document your sysfs
    interfaces, that is what it is there for...

    thanks,

    greg k-h

    ---------------
    From: Greg Kroah-Hartman
    Subject: perfmon: fix up some static kobject usages

    This gets the perfmon code to build properly on the latest -mm tree, as
    well as removing some static kobjects.

    A lot of future kobject cleanups can be done on this code, but the
    documentation for the perfmon sysfs interface is very limited and does
    not describe all of the different files and subdirectories at all.

    Signed-off-by: Greg Kroah-Hartman

    ---
    perfmon/perfmon_sysfs.c | 37 +++++++++++++++----------------------
    1 file changed, 15 insertions(+), 22 deletions(-)

    --- a/perfmon/perfmon_sysfs.c
    +++ b/perfmon/perfmon_sysfs.c
    @@ -76,7 +76,8 @@ EXPORT_SYMBOL(pfm_controls);

    DECLARE_PER_CPU(struct pfm_stats, pfm_stats);

    -static struct kobject pfm_kernel_kobj, pfm_kernel_fmt_kobj;
    +static struct kobject *pfm_kernel_kobj;
    +static struct kobject *pfm_kernel_fmt_kobj;

    static void pfm_reset_stats(int cpu)
    {
    @@ -402,31 +403,23 @@ static struct attribute_group pfm_kernel

    int __init pfm_init_sysfs(void)
    {
    - int ret;
    + int ret = -ENOMEM;
    int i, cpu = -1;

    - kobject_init(&pfm_kernel_kobj);
    - kobject_init(&pfm_kernel_fmt_kobj);
    -
    - pfm_kernel_kobj.parent = &kernel_subsys.kobj;
    - kobject_set_name(&pfm_kernel_kobj, "perfmon");
    -
    - pfm_kernel_fmt_kobj.parent = &pfm_kernel_kobj;
    - kobject_set_name(&pfm_kernel_fmt_kobj, "formats");
    -
    - ret = kobject_add(&pfm_kernel_kobj);
    - if (ret) {
    - PFM_INFO("cannot add kernel object: %d", ret);
    + pfm_kernel_kobj = kobject_create_and_register("perfmon", kernel_kobj);
    + if (!pfm_kernel_kobj) {
    + PFM_INFO("cannot create perfmon kernel object");
    goto error;
    }

    - ret = kobject_add(&pfm_kernel_fmt_kobj);
    - if (ret) {
    - PFM_INFO("cannot add fmt object: %d", ret);
    + pfm_kernel_fmt_kobj = kobject_create_and_register("formats",
    + pfm_kernel_kobj);
    + if (!pfm_kernel_fmt_kobj) {
    + PFM_INFO("cannot add fmt object");
    goto error_fmt;
    }

    - ret = sysfs_create_group(&pfm_kernel_kobj, &pfm_kernel_attr_group);
    + ret = sysfs_create_group(pfm_kernel_kobj, &pfm_kernel_attr_group);
    if (ret) {
    PFM_INFO("cannot create kernel group");
    goto error_group;
    @@ -449,9 +442,9 @@ int __init pfm_init_sysfs(void)
    return 0;

    error_group:
    - kobject_del(&pfm_kernel_fmt_kobj);
    + kobject_unregister(pfm_kernel_fmt_kobj);
    error_fmt:
    - kobject_del(&pfm_kernel_kobj);
    + kobject_unregister(pfm_kernel_kobj);

    for (i=0; i < cpu; i++)
    pfm_sysfs_del_cpu(i);
    @@ -683,7 +676,7 @@ int pfm_sysfs_add_fmt(struct pfm_smpl_fm

    kobject_set_name(&fmt->kobj, fmt->fmt_name);
    //kobj_set_kset_s(fmt, pfm_fmt_subsys);
    - fmt->kobj.parent = &pfm_kernel_fmt_kobj;
    + fmt->kobj.parent = pfm_kernel_fmt_kobj;

    ret = kobject_add(&fmt->kobj);
    if (ret)
    @@ -861,7 +854,7 @@ int pfm_sysfs_add_pmu(struct pfm_pmu_con
    kobject_init(&pmu->kobj);
    kobject_set_name(&pmu->kobj, "pmu_desc");
    //kobj_set_kset_s(pmu, pfm_pmu_subsys);
    - pmu->kobj.parent = &pfm_kernel_kobj;
    + pmu->kobj.parent = pfm_kernel_kobj;

    ret = kobject_add(&pmu->kobj);
    if (ret)
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH] fix up perfmon to build on -mm

    Greg,

    On Tue, Nov 06, 2007 at 04:34:54PM -0800, Greg KH wrote:
    > Here's a patch against my current tree that gets the perfmon code
    > building and hopefully working.
    >

    Thanks for your quick help.

    > Note, it needs the kobject_create_and_register() patch which is in my
    > tree, but I do not think it made it to -mm yet. The next -mm cycle
    > should have it.
    >
    > Also, the sysfs usage in the perfmon code is quite strange and not
    > documented at all. Yes, there is a little bit in the documentation
    > about what a few of the files do, but there are _way_ more files and
    > even directories being created under /sys/kernel/perfmon/ that are not
    > documented at all here.
    >

    The full documentation for /sys/kernel/perfmon is in Documentation/perfmon2.txt

    > If you document this stuff, I think I can clean up your sysfs code a
    > lot, making things simpler, easier to extend, and easier to understand.
    > But as it is, I don't want to break anything as it's totally unknown how
    > this stuff is supposed to work...
    >

    I certainly welcome your help.

    > Hint, use the Documentation/ABI directory to document your sysfs
    > interfaces, that is what it is there for...
    >

    I will move the description from perfmon2.txt to its own file in
    ABI/testing.

    --
    -Stephane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH] fix up perfmon to build on -mm

    Greg,

    Perfmon sysfs document has been updated following your adivce.
    you can check out in my perfmon tree the following commit:

    e83278f879e52ecee025effe9ad509fd51e4a516

    Thanks.

    On Tue, Nov 06, 2007 at 04:34:54PM -0800, Greg KH wrote:
    > Here's a patch against my current tree that gets the perfmon code
    > building and hopefully working.
    >
    > Note, it needs the kobject_create_and_register() patch which is in my
    > tree, but I do not think it made it to -mm yet. The next -mm cycle
    > should have it.
    >
    > Also, the sysfs usage in the perfmon code is quite strange and not
    > documented at all. Yes, there is a little bit in the documentation
    > about what a few of the files do, but there are _way_ more files and
    > even directories being created under /sys/kernel/perfmon/ that are not
    > documented at all here.
    >
    > If you document this stuff, I think I can clean up your sysfs code a
    > lot, making things simpler, easier to extend, and easier to understand.
    > But as it is, I don't want to break anything as it's totally unknown how
    > this stuff is supposed to work...
    >
    > Hint, use the Documentation/ABI directory to document your sysfs
    > interfaces, that is what it is there for...
    >
    > thanks,
    >
    > greg k-h
    >
    > ---------------
    > From: Greg Kroah-Hartman
    > Subject: perfmon: fix up some static kobject usages
    >
    > This gets the perfmon code to build properly on the latest -mm tree, as
    > well as removing some static kobjects.
    >
    > A lot of future kobject cleanups can be done on this code, but the
    > documentation for the perfmon sysfs interface is very limited and does
    > not describe all of the different files and subdirectories at all.
    >
    > Signed-off-by: Greg Kroah-Hartman
    >
    > ---
    > perfmon/perfmon_sysfs.c | 37 +++++++++++++++----------------------
    > 1 file changed, 15 insertions(+), 22 deletions(-)
    >
    > --- a/perfmon/perfmon_sysfs.c
    > +++ b/perfmon/perfmon_sysfs.c
    > @@ -76,7 +76,8 @@ EXPORT_SYMBOL(pfm_controls);
    >
    > DECLARE_PER_CPU(struct pfm_stats, pfm_stats);
    >
    > -static struct kobject pfm_kernel_kobj, pfm_kernel_fmt_kobj;
    > +static struct kobject *pfm_kernel_kobj;
    > +static struct kobject *pfm_kernel_fmt_kobj;
    >
    > static void pfm_reset_stats(int cpu)
    > {
    > @@ -402,31 +403,23 @@ static struct attribute_group pfm_kernel
    >
    > int __init pfm_init_sysfs(void)
    > {
    > - int ret;
    > + int ret = -ENOMEM;
    > int i, cpu = -1;
    >
    > - kobject_init(&pfm_kernel_kobj);
    > - kobject_init(&pfm_kernel_fmt_kobj);
    > -
    > - pfm_kernel_kobj.parent = &kernel_subsys.kobj;
    > - kobject_set_name(&pfm_kernel_kobj, "perfmon");
    > -
    > - pfm_kernel_fmt_kobj.parent = &pfm_kernel_kobj;
    > - kobject_set_name(&pfm_kernel_fmt_kobj, "formats");
    > -
    > - ret = kobject_add(&pfm_kernel_kobj);
    > - if (ret) {
    > - PFM_INFO("cannot add kernel object: %d", ret);
    > + pfm_kernel_kobj = kobject_create_and_register("perfmon", kernel_kobj);
    > + if (!pfm_kernel_kobj) {
    > + PFM_INFO("cannot create perfmon kernel object");
    > goto error;
    > }
    >
    > - ret = kobject_add(&pfm_kernel_fmt_kobj);
    > - if (ret) {
    > - PFM_INFO("cannot add fmt object: %d", ret);
    > + pfm_kernel_fmt_kobj = kobject_create_and_register("formats",
    > + pfm_kernel_kobj);
    > + if (!pfm_kernel_fmt_kobj) {
    > + PFM_INFO("cannot add fmt object");
    > goto error_fmt;
    > }
    >
    > - ret = sysfs_create_group(&pfm_kernel_kobj, &pfm_kernel_attr_group);
    > + ret = sysfs_create_group(pfm_kernel_kobj, &pfm_kernel_attr_group);
    > if (ret) {
    > PFM_INFO("cannot create kernel group");
    > goto error_group;
    > @@ -449,9 +442,9 @@ int __init pfm_init_sysfs(void)
    > return 0;
    >
    > error_group:
    > - kobject_del(&pfm_kernel_fmt_kobj);
    > + kobject_unregister(pfm_kernel_fmt_kobj);
    > error_fmt:
    > - kobject_del(&pfm_kernel_kobj);
    > + kobject_unregister(pfm_kernel_kobj);
    >
    > for (i=0; i < cpu; i++)
    > pfm_sysfs_del_cpu(i);
    > @@ -683,7 +676,7 @@ int pfm_sysfs_add_fmt(struct pfm_smpl_fm
    >
    > kobject_set_name(&fmt->kobj, fmt->fmt_name);
    > //kobj_set_kset_s(fmt, pfm_fmt_subsys);
    > - fmt->kobj.parent = &pfm_kernel_fmt_kobj;
    > + fmt->kobj.parent = pfm_kernel_fmt_kobj;
    >
    > ret = kobject_add(&fmt->kobj);
    > if (ret)
    > @@ -861,7 +854,7 @@ int pfm_sysfs_add_pmu(struct pfm_pmu_con
    > kobject_init(&pmu->kobj);
    > kobject_set_name(&pmu->kobj, "pmu_desc");
    > //kobj_set_kset_s(pmu, pfm_pmu_subsys);
    > - pmu->kobj.parent = &pfm_kernel_kobj;
    > + pmu->kobj.parent = pfm_kernel_kobj;
    >
    > ret = kobject_add(&pmu->kobj);
    > if (ret)


    --

    -Stephane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH] fix up perfmon to build on -mm

    On Wed, Nov 07, 2007 at 05:42:55AM -0800, Stephane Eranian wrote:
    > Greg,
    >
    > Perfmon sysfs document has been updated following your adivce.
    > you can check out in my perfmon tree the following commit:
    >
    > e83278f879e52ecee025effe9ad509fd51e4a516


    Where is this git tree located? On git.kernel.org somewhere?

    thanks,

    greg k-h
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH] fix up perfmon to build on -mm

    On Wed, Nov 07, 2007 at 02:34:49AM -0800, Stephane Eranian wrote:
    > Greg,
    >
    > On Tue, Nov 06, 2007 at 04:34:54PM -0800, Greg KH wrote:
    > > Here's a patch against my current tree that gets the perfmon code
    > > building and hopefully working.
    > >

    > Thanks for your quick help.
    >
    > > Note, it needs the kobject_create_and_register() patch which is in my
    > > tree, but I do not think it made it to -mm yet. The next -mm cycle
    > > should have it.
    > >
    > > Also, the sysfs usage in the perfmon code is quite strange and not
    > > documented at all. Yes, there is a little bit in the documentation
    > > about what a few of the files do, but there are _way_ more files and
    > > even directories being created under /sys/kernel/perfmon/ that are not
    > > documented at all here.
    > >

    > The full documentation for /sys/kernel/perfmon is in Documentation/perfmon2.txt


    That is what I was referring to, that file does not describe all of the
    sysfs files in /sys/kernel/perfmon by far.

    > > If you document this stuff, I think I can clean up your sysfs code a
    > > lot, making things simpler, easier to extend, and easier to understand.
    > > But as it is, I don't want to break anything as it's totally unknown how
    > > this stuff is supposed to work...
    > >

    > I certainly welcome your help.
    >
    > > Hint, use the Documentation/ABI directory to document your sysfs
    > > interfaces, that is what it is there for...
    > >

    > I will move the description from perfmon2.txt to its own file in
    > ABI/testing.


    That would be great to have, thanks.

    greg k-h
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH] fix up perfmon to build on -mm

    > On Wed, 7 Nov 2007 09:08:20 -0800 Greg KH wrote:
    > On Wed, Nov 07, 2007 at 05:42:55AM -0800, Stephane Eranian wrote:
    > > Greg,
    > >
    > > Perfmon sysfs document has been updated following your adivce.
    > > you can check out in my perfmon tree the following commit:
    > >
    > > e83278f879e52ecee025effe9ad509fd51e4a516

    >
    > Where is this git tree located? On git.kernel.org somewhere?
    >



    I get mine from git+ssh://master.kernel.org/pub/scm/linux/kernel/git/eranian/linux-2.6.git
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH] fix up perfmon to build on -mm

    On Wed, Nov 07, 2007 at 09:33:13AM -0800, Andrew Morton wrote:
    > > On Wed, 7 Nov 2007 09:08:20 -0800 Greg KH wrote:
    > > On Wed, Nov 07, 2007 at 05:42:55AM -0800, Stephane Eranian wrote:
    > > > Greg,
    > > >
    > > > Perfmon sysfs document has been updated following your adivce.
    > > > you can check out in my perfmon tree the following commit:
    > > >
    > > > e83278f879e52ecee025effe9ad509fd51e4a516

    > >
    > > Where is this git tree located? On git.kernel.org somewhere?
    > >

    >
    >
    > I get mine from git+ssh://master.kernel.org/pub/scm/linux/kernel/git/eranian/linux-2.6.git


    Thanks, that worked, let me go read the new documentation...
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH] fix up perfmon to build on -mm

    On Wed, Nov 07, 2007 at 09:08:20AM -0800, Greg KH wrote:
    > On Wed, Nov 07, 2007 at 05:42:55AM -0800, Stephane Eranian wrote:
    > > Greg,
    > >
    > > Perfmon sysfs document has been updated following your adivce.
    > > you can check out in my perfmon tree the following commit:
    > >
    > > e83278f879e52ecee025effe9ad509fd51e4a516

    >
    > Where is this git tree located? On git.kernel.org somewhere?
    >

    http://git.kernel.org/?p=linux/kerne.../linux-2.6.git

    --
    -Stephane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH] fix up perfmon to build on -mm

    Greg,

    On Wed, Nov 07, 2007 at 09:47:47AM -0800, Greg KH wrote:
    > On Wed, Nov 07, 2007 at 05:42:55AM -0800, Stephane Eranian wrote:
    > > Greg,
    > >
    > > Perfmon sysfs document has been updated following your adivce.
    > > you can check out in my perfmon tree the following commit:
    > >
    > > e83278f879e52ecee025effe9ad509fd51e4a516

    >
    > Thanks, that looks a lot better.
    >
    > Do you want me to send you patches based on this tree to help clean up
    > the sysfs usage now that it's documented?
    >

    Yes, send me the patches. But from what you were saying earlier it seems
    I would need an extra sysfs patches to make this compile. Is that particular
    patch already in Linus's tree?


    > Also, a lot of your per-cpu sysfs files should probably move to debugfs
    > as they are for debugging only, right? No need to clutter up sysfs with
    > them when only the very few perfmon developers would be needing access
    > to them.
    >

    Yes, this is mostly debugging. If debugfs is meant for this, then I'll
    be happy to move this stuff over there. Is there some good example of how
    I could do that based on my current sysfs code?

    Thanks.

    --
    -Stephane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH] fix up perfmon to build on -mm

    On Wed, Nov 07, 2007 at 05:42:55AM -0800, Stephane Eranian wrote:
    > Greg,
    >
    > Perfmon sysfs document has been updated following your adivce.
    > you can check out in my perfmon tree the following commit:
    >
    > e83278f879e52ecee025effe9ad509fd51e4a516


    Thanks, that looks a lot better.

    Do you want me to send you patches based on this tree to help clean up
    the sysfs usage now that it's documented?

    Also, a lot of your per-cpu sysfs files should probably move to debugfs
    as they are for debugging only, right? No need to clutter up sysfs with
    them when only the very few perfmon developers would be needing access
    to them.

    thanks,

    greg k-h
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH] fix up perfmon to build on -mm

    On Wed, Nov 07, 2007 at 09:57:42AM -0800, Stephane Eranian wrote:
    > Greg,
    >
    > On Wed, Nov 07, 2007 at 09:47:47AM -0800, Greg KH wrote:
    > > On Wed, Nov 07, 2007 at 05:42:55AM -0800, Stephane Eranian wrote:
    > > > Greg,
    > > >
    > > > Perfmon sysfs document has been updated following your adivce.
    > > > you can check out in my perfmon tree the following commit:
    > > >
    > > > e83278f879e52ecee025effe9ad509fd51e4a516

    > >
    > > Thanks, that looks a lot better.
    > >
    > > Do you want me to send you patches based on this tree to help clean up
    > > the sysfs usage now that it's documented?
    > >

    > Yes, send me the patches. But from what you were saying earlier it seems
    > I would need an extra sysfs patches to make this compile. Is that particular
    > patch already in Linus's tree?


    No, it's in my tree, and will be in the next -mm. You will need a few
    patches to get this to work, not just a single patch.

    > > Also, a lot of your per-cpu sysfs files should probably move to debugfs
    > > as they are for debugging only, right? No need to clutter up sysfs with
    > > them when only the very few perfmon developers would be needing access
    > > to them.
    > >

    > Yes, this is mostly debugging. If debugfs is meant for this, then I'll
    > be happy to move this stuff over there. Is there some good example of how
    > I could do that based on my current sysfs code?


    There is documentation for debugfs in the kernel api document

    And, there are many in-kernel users of debugfs, a grep for
    "debugfs_create_" should show you some examples of how to use this. If
    you have any questions, please let me know.

    thanks,

    greg k-h
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH] fix up perfmon to build on -mm

    Greg,

    On Wed, Nov 07, 2007 at 11:53:20AM -0800, Greg KH wrote:
    > > >
    > > > Do you want me to send you patches based on this tree to help clean up
    > > > the sysfs usage now that it's documented?
    > > >

    > > Yes, send me the patches. But from what you were saying earlier it seems
    > > I would need an extra sysfs patches to make this compile. Is that particular
    > > patch already in Linus's tree?

    >
    > No, it's in my tree, and will be in the next -mm. You will need a few
    > patches to get this to work, not just a single patch.
    >

    Could you send them to me? if they are not too intrusive I could add them
    to my tree. Yet I don't want something to distant from Linus's tree which
    I pull from. My goal is to ensure that my tree still compiles and works.

    > > > Also, a lot of your per-cpu sysfs files should probably move to debugfs
    > > > as they are for debugging only, right? No need to clutter up sysfs with
    > > > them when only the very few perfmon developers would be needing access
    > > > to them.
    > > >

    > > Yes, this is mostly debugging. If debugfs is meant for this, then I'll
    > > be happy to move this stuff over there. Is there some good example of how
    > > I could do that based on my current sysfs code?

    >
    > There is documentation for debugfs in the kernel api document
    >
    > And, there are many in-kernel users of debugfs, a grep for
    > "debugfs_create_" should show you some examples of how to use this. If
    > you have any questions, please let me know.
    >

    Ok, I'll look at that next.

    Thanks,

    --

    -Stephane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH] fix up perfmon to build on -mm

    Greg,

    On Wed, Nov 07, 2007 at 11:53:20AM -0800, Greg KH wrote:
    > > > Also, a lot of your per-cpu sysfs files should probably move to debugfs
    > > > as they are for debugging only, right? No need to clutter up sysfs with
    > > > them when only the very few perfmon developers would be needing access
    > > > to them.
    > > >

    > > Yes, this is mostly debugging. If debugfs is meant for this, then I'll
    > > be happy to move this stuff over there. Is there some good example of how
    > > I could do that based on my current sysfs code?

    >
    > There is documentation for debugfs in the kernel api document
    >
    > And, there are many in-kernel users of debugfs, a grep for
    > "debugfs_create_" should show you some examples of how to use this. If
    > you have any questions, please let me know.


    I have now removed all the perfmon2 statistics from sysfs and moved them
    to debugfs. I must admit, I like it better this way. Debugfs is also so
    much easier to program.

    Patch has been pushed into my tree. Let me know if you think I can improve
    the sysfs code some more.

    Thanks.

    --

    -Stephane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH] fix up perfmon to build on -mm

    On Tue, 6 Nov 2007 16:34:54 -0800
    Greg KH wrote:

    > Here's a patch against my current tree that gets the perfmon code
    > building and hopefully working.


    Unfortunately I still haven't merged perfmon due to recently-occurring
    minor conflicts with Tony's ia64 tree and more major recently-occurring
    conflicts with the x86 tree.

    There's not really a lot which Stephane can practically do about this -
    normally I'll just get down and fix stuff like this up. But the impression
    I get from various people is that the perfmon tree in its present form
    would not be a popular merge.

    The impression which people have (and I admit to sharing it) is that
    there's just too much stuff in there and it might not all be justifiable.
    But I suspect that people have largely forgotten what is in there, and why
    it is in there.

    We really need to get this ball rolling, and that will require a sustained
    effort from more people than just Stephane. I suppose as a starting point
    we could yet again review the existing patches, please. People will mainly
    concentrate upon the changelogging to understand which features are being
    proposed and why, so that submission should describe these things pretty
    carefully: what are the features and why do we need each of them.

    tia.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH] fix up perfmon to build on -mm

    On Fri, Nov 09, 2007 at 12:06:27PM -0800, Andrew Morton wrote:
    > On Tue, 6 Nov 2007 16:34:54 -0800
    > Greg KH wrote:
    >
    > > Here's a patch against my current tree that gets the perfmon code
    > > building and hopefully working.

    >
    > Unfortunately I still haven't merged perfmon due to recently-occurring
    > minor conflicts with Tony's ia64 tree and more major recently-occurring
    > conflicts with the x86 tree.
    >
    > There's not really a lot which Stephane can practically do about this -
    > normally I'll just get down and fix stuff like this up. But the impression
    > I get from various people is that the perfmon tree in its present form
    > would not be a popular merge.
    >
    > The impression which people have (and I admit to sharing it) is that
    > there's just too much stuff in there and it might not all be justifiable.
    > But I suspect that people have largely forgotten what is in there, and why
    > it is in there.
    >
    > We really need to get this ball rolling, and that will require a sustained
    > effort from more people than just Stephane. I suppose as a starting point
    > we could yet again review the existing patches, please. People will mainly
    > concentrate upon the changelogging to understand which features are being
    > proposed and why, so that submission should describe these things pretty
    > carefully: what are the features and why do we need each of them.


    Is there some way to rebase these patches/git tree to be a bit more easy
    to review? Right now there are over 75 patches in the tree and many (if
    not most) can be removed by merging them with previous patches.

    If someone could break this stuff down into reviewable pieces, it would
    go a very long way toward making it acceptable.

    Is there any way to just provide a basic framework that everyone can
    agree on and then add on more stuff as time goes on? Do we have to have
    every different processor/arch with support to start with?

    thanks,

    greg k-h
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH] fix up perfmon to build on -mm

    Greg KH writes:

    [dropped perfmon list because gmane messed it up and it's apparently
    closed anyways]

    > Is there any way to just provide a basic framework that everyone can
    > agree on and then add on more stuff as time goes on? Do we have to have
    > every different processor/arch with support to start with?


    I think the real problem are not the architectures (the processor
    adaption layer is usually relatively straight forward IIRC), but the
    excessive functionality implemented by the user interface.

    It would be really good to extract a core perfmon and start with
    that and then add stuff as it makes sense.

    e.g. core perfmon could be something simple like just support
    to context switch state and initialize counters in a basic way
    and perhaps get counter numbers for RDPMC in ring3 on x86[1]

    Next step could be basic event on overflow/underflow support.

    Then more features as they make sense, with clear rationale
    what they're good for and proper step by step patches.

    -Andi

    [1] On x86 we urgently need a replacement to RDTSC for counting
    cycles.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. perfmon2 merge news

    On 10.11.07 21:32:39, Andi Kleen wrote:
    > It would be really good to extract a core perfmon and start with
    > that and then add stuff as it makes sense.
    >
    > e.g. core perfmon could be something simple like just support
    > to context switch state and initialize counters in a basic way
    > and perhaps get counter numbers for RDPMC in ring3 on x86[1]


    Perhaps a core could provide also as much functionality so that
    Perfmon can be used with an *unpatched* kernel using loadable modules?
    One drawback with today's Perfmon is that it can not be used with a
    vanilla kernel. But maybe such a core is by far too complex for a
    first merge.

    -Robert

    --
    Advanced Micro Devices, Inc.
    Operating System Research Center
    email: robert.richter@amd.com


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [perfmon2] perfmon2 merge news

    Robert Richter wrote:
    > On 10.11.07 21:32:39, Andi Kleen wrote:
    >> It would be really good to extract a core perfmon and start with
    >> that and then add stuff as it makes sense.
    >>
    >> e.g. core perfmon could be something simple like just support
    >> to context switch state and initialize counters in a basic way
    >> and perhaps get counter numbers for RDPMC in ring3 on x86[1]

    >
    > Perhaps a core could provide also as much functionality so that
    > Perfmon can be used with an *unpatched* kernel using loadable modules?
    > One drawback with today's Perfmon is that it can not be used with a
    > vanilla kernel. But maybe such a core is by far too complex for a
    > first merge.
    >
    > -Robert
    >


    Hi Robert,

    In the past I suggested that it might be useful to have a version of perfmon2
    that only set up the perfmon on a global basis. That would allow the patches for
    context switches to be added as a separate step, splitting up the patch into
    smaller set of patches.

    Perfmon2 uses a set of system calls to control the performance monitoring
    hardware. This would make it difficult to use an unpatch kernel unless perfmon
    changed the mechanism used to control the performance monitoring hardware.

    -Will
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [perfmon2] perfmon2 merge news

    Hello,

    On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote:
    > Robert Richter wrote:
    > > On 10.11.07 21:32:39, Andi Kleen wrote:
    > >> It would be really good to extract a core perfmon and start with
    > >> that and then add stuff as it makes sense.
    > >>
    > >> e.g. core perfmon could be something simple like just support
    > >> to context switch state and initialize counters in a basic way
    > >> and perhaps get counter numbers for RDPMC in ring3 on x86[1]

    > >
    > > Perhaps a core could provide also as much functionality so that
    > > Perfmon can be used with an *unpatched* kernel using loadable modules?
    > > One drawback with today's Perfmon is that it can not be used with a
    > > vanilla kernel. But maybe such a core is by far too complex for a
    > > first merge.
    > >
    > > -Robert
    > >

    >
    > Hi Robert,
    >
    > In the past I suggested that it might be useful to have a version of perfmon2
    > that only set up the perfmon on a global basis. That would allow the patches for
    > context switches to be added as a separate step, splitting up the patch into
    > smaller set of patches.
    >
    > Perfmon2 uses a set of system calls to control the performance monitoring
    > hardware. This would make it difficult to use an unpatch kernel unless perfmon
    > changed the mechanism used to control the performance monitoring hardware.
    >

    Yes, that would be a possibility but as you pointed out there are some problems:

    - perfmon2 uses system calls. So unless you can dynamically patch the
    syscall table we would have to go back to the ioctl() and driver model.
    I was under the impression that people did not quite like multiplexing
    syscalls such as ioctl(). I also do prefer the multi syscall approach.

    - perfmon2 needs to install a PMU interrupt handler. On X86, this is not just
    an external device interrupts. There needs to be some APIC and interrupt
    gate setup. There maybe other constraints on other architectures as well.
    Not sure if all functions/structures necessary for this are available to
    modules.

    - we could not support per-thread mode with the kernel module approach due to
    link to the context switch code. I do believe per-thread is a key value-add
    for performance monitoring.

    --
    -Stephane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: perfmon2 merge news

    Hello,

    On Tue, Nov 13, 2007 at 04:17:18PM +0100, Robert Richter wrote:
    > On 10.11.07 21:32:39, Andi Kleen wrote:
    > > It would be really good to extract a core perfmon and start with
    > > that and then add stuff as it makes sense.
    > >
    > > e.g. core perfmon could be something simple like just support
    > > to context switch state and initialize counters in a basic way
    > > and perhaps get counter numbers for RDPMC in ring3 on x86[1]

    >
    > Perhaps a core could provide also as much functionality so that
    > Perfmon can be used with an *unpatched* kernel using loadable modules?
    > One drawback with today's Perfmon is that it can not be used with a
    > vanilla kernel. But maybe such a core is by far too complex for a
    > first merge.
    >

    Note that I am not against the gradual approach such as:
    - system-wide only counting
    - per-thread counting
    - user-level sampling support
    - in-kernel sampling buffer support
    - in-kernel customizable sampling buffer formats via modules
    - event set multiplexing
    - PMU description modules

    It would obvisouly cause a lot of troubles to existing perfmon libraries and
    applications (e.g. PAPI). It would also be fairly tricky to do because you'd
    have to make sure that in the beginning, you leave enough flexiblity such that
    you can add the rest while maintaining total backward compatibility. But given
    that we already have the full solution, it could just be a matter of dropping
    features without disrupting the user level API. Of course there would be a bigger
    burden on the maintainer because he would have two trees to maintain but I think
    that is already commonplace in many of the kernel-related projects.

    Let's take a simple example. The set of syscalls necessary to control a system-wide
    monitoring session is exactly the same as for a per-thread session. The difference is
    just a flag when the session is created. Thus, we could keep the same set of syscalls,
    but only accept system-wide sessions. Later on, when we add per-thread, we would just
    have to expose the per-thread session flag.

    Having said that, does not mean that this is necessarily what we will do. I am just
    try to present my understanding of the comments from Andrew, Andi and others.

    I think that going with a kernel module will not address the 'complexity/bloat' perception
    that some people have. There is a logic to that, I did not just wakeup one day saying
    'wouldn't it be cool to add set multiplexing?'. There was a true need expressed by users or
    developers and it was justfied by what the hardware offered then. This unfortunately still
    stands today. I admit that justification is not necessarily spelled out clearly in the code. So
    I understand most of those worries and I am trying to figure out how we could best address them.

    --
    -Stephane
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 6 1 2 3 ... LastLast