Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1194678 > unrolled thread
| Started by | Andrew Morton <akpm@linux-foundation.org> |
|---|---|
| First post | 2015-07-28 23:30 +0200 |
| Last post | 2015-08-03 04:50 +0200 |
| Articles | 5 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2] kthread: Export kthread functions Andrew Morton <akpm@linux-foundation.org> - 2015-07-28 23:30 +0200
Re: [PATCH v2] kthread: Export kthread functions yalin wang <yalin.wang2010@gmail.com> - 2015-07-30 05:50 +0200
Re: [PATCH v2] kthread: Export kthread functions yalin wang <yalin.wang2010@gmail.com> - 2015-07-31 06:20 +0200
Re: [PATCH v2] kthread: Export kthread functions yalin wang <yalin.wang2010@gmail.com> - 2015-08-03 04:30 +0200
Re: [PATCH v2] kthread: Export kthread functions Jes Sorensen <Jes.Sorensen@redhat.com> - 2015-08-03 04:50 +0200
| From | Andrew Morton <akpm@linux-foundation.org> |
|---|---|
| Date | 2015-07-28 23:30 +0200 |
| Subject | Re: [PATCH v2] kthread: Export kthread functions |
| Message-ID | <pRkBI-4uH-5@gated-at.bofh.it> |
On Tue, 28 Jul 2015 11:59:01 -0400 David Kershner <david.kershner@unisys.com> wrote: > The s-Par visornic driver, currently in staging, processes a queue > being serviced by the an s-Par service partition. We can get a message > that something has happened with the Service Partition, when that > happens, we must not access the channel until we get a message that the > service partition is back again. > > The visornic driver has a thread for processing the channel, when we > get the message, we need to be able to park the thread and then resume > it when the problem clears. > > We can do this with kthread_park and unpark but they are not exported > from the kernel, this patch exports the needed functions. > > Signed-off-by: David Kershner <david.kershner@unisys.com> Please accumulate the acked-by's and reviewed-by's in the changelog as they are received. I presently have Acked-by: Ingo Molnar <mingo@kernel.org> Acked-by: Neil Horman <nhorman@tuxdriver.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Richard Weinberger <richard.weinberger@gmail.com> Cc: Tejun Heo <tj@kernel.org> I'll scoot this into mainline probably this week to make life simpler for the various trees. -- 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/
[toc] | [next] | [standalone]
| From | yalin wang <yalin.wang2010@gmail.com> |
|---|---|
| Date | 2015-07-30 05:50 +0200 |
| Message-ID | <pRN10-3ho-11@gated-at.bofh.it> |
| In reply to | #1194678 |
> On Jul 29, 2015, at 18:34, Thomas Gleixner <tglx@linutronix.de> wrote: > > On Tue, 28 Jul 2015, Andrew Morton wrote: > >> On Tue, 28 Jul 2015 11:59:01 -0400 David Kershner <david.kershner@unisys.com> wrote: >> >>> The s-Par visornic driver, currently in staging, processes a queue >>> being serviced by the an s-Par service partition. We can get a message >>> that something has happened with the Service Partition, when that >>> happens, we must not access the channel until we get a message that the >>> service partition is back again. >>> >>> The visornic driver has a thread for processing the channel, when we >>> get the message, we need to be able to park the thread and then resume >>> it when the problem clears. >>> >>> We can do this with kthread_park and unpark but they are not exported >>> from the kernel, this patch exports the needed functions. >>> >>> Signed-off-by: David Kershner <david.kershner@unisys.com> >> >> Please accumulate the acked-by's and reviewed-by's in the changelog as >> they are received. I presently have >> >> Acked-by: Ingo Molnar <mingo@kernel.org> >> Acked-by: Neil Horman <nhorman@tuxdriver.com> >> Cc: Thomas Gleixner <tglx@linutronix.de> >> Cc: Richard Weinberger <richard.weinberger@gmail.com> >> Cc: Tejun Heo <tj@kernel.org> >> >> >> I'll scoot this into mainline probably this week to make life simpler >> for the various trees. > i am curious why not make some tiny functions to be inline ? so that don’t need EXPORT_SYMOBLS , shrink the kernel size. Thanks-- 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/
[toc] | [prev] | [next] | [standalone]
| From | yalin wang <yalin.wang2010@gmail.com> |
|---|---|
| Date | 2015-07-31 06:20 +0200 |
| Message-ID | <pS9Xz-2S8-7@gated-at.bofh.it> |
| In reply to | #1195702 |
> On Jul 30, 2015, at 20:02, Neil Horman <nhorman@redhat.com> wrote:
>
> On Thu, Jul 30, 2015 at 11:48:17AM +0800, yalin wang wrote:
>>
>>> On Jul 29, 2015, at 18:34, Thomas Gleixner <tglx@linutronix.de> wrote:
>>>
>>> On Tue, 28 Jul 2015, Andrew Morton wrote:
>>>
>>>> On Tue, 28 Jul 2015 11:59:01 -0400 David Kershner <david.kershner@unisys.com> wrote:
>>>>
>>>>> The s-Par visornic driver, currently in staging, processes a queue
>>>>> being serviced by the an s-Par service partition. We can get a message
>>>>> that something has happened with the Service Partition, when that
>>>>> happens, we must not access the channel until we get a message that the
>>>>> service partition is back again.
>>>>>
>>>>> The visornic driver has a thread for processing the channel, when we
>>>>> get the message, we need to be able to park the thread and then resume
>>>>> it when the problem clears.
>>>>>
>>>>> We can do this with kthread_park and unpark but they are not exported
>>>>> from the kernel, this patch exports the needed functions.
>>>>>
>>>>> Signed-off-by: David Kershner <david.kershner@unisys.com>
>>>>
>>>> Please accumulate the acked-by's and reviewed-by's in the changelog as
>>>> they are received. I presently have
>>>>
>>>> Acked-by: Ingo Molnar <mingo@kernel.org>
>>>> Acked-by: Neil Horman <nhorman@tuxdriver.com>
>>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>>> Cc: Richard Weinberger <richard.weinberger@gmail.com>
>>>> Cc: Tejun Heo <tj@kernel.org>
>>>>
>>>>
>>>> I'll scoot this into mainline probably this week to make life simpler
>>>> for the various trees.
>>>
>> i am curious why not make some tiny functions to be inline ?
>> so that don’t need EXPORT_SYMOBLS , shrink the kernel size.
>> Thanks
>
> Because exporting symbols isn't a big deal, and the compiler can decide when its
> best to inline these functions. As it is, they aren't that small, if you expand
> all their internals
>
> Neil
>
this is my test on arm64 arch,
i think kthread_should_stop() kthread_should_park() kthread_data() should be inline :
without inline:
ffffffc0000d265c <smpboot_thread_fn>:
……….
ffffffc0000d26a0: b9001a61 str w1, [x19,#24]
ffffffc0000d26a4: 97fff260 bl ffffffc0000cf024 <kthread_should_stop>
ffffffc0000d26a8: 53001c00 uxtb w0, w0
ffffffc0000d26ac: 35000c20 cbnz w0, ffffffc0000d2830 <smpboot_thread_fn+0x1d4>
ffffffc0000d26b0: 97fff4aa bl ffffffc0000cf958 <kthread_should_park>
ffffffc0000d26b4: 53001c00 uxtb w0, w0
ffffffc0000d26b8: 34000320 cbz w0, ffffffc0000d271c <smpboot_thread_fn+0xc0>
ffffffc0000d26bc: f9400a60 ldr x0, [x19,#16]
ffffffc0000d26c0: f900001f str xzr, [x0]
ffffffc0000cf958 <kthread_should_park>:
ffffffc0000cf958: 910003e0 mov x0, sp
ffffffc0000cf95c: 9272c400 and x0, x0, #0xffffffffffffc000
ffffffc0000cf960: f9400800 ldr x0, [x0,#16]
ffffffc0000cf964: f9420400 ldr x0, [x0,#1032]
ffffffc0000cf968: f85c8000 ldr x0, [x0,#-56]
ffffffc0000cf96c: d3420800 ubfx x0, x0, #2, #1
ffffffc0000cf970: d65f03c0 ret
if i mark kthread_should_park to be inline :
ffffffc0000d19ec <smpboot_thread_fn>:
ffffffc0000d19ec: a9bc7bfd stp x29, x30, [sp,#-64]!
ffffffc0000d19f0: 910003fd mov x29, sp
ffffffc0000d19f4: a90153f3 stp x19, x20, [sp,#16]
ffffffc0000d19f8: aa0003f4 mov x20, x0
ffffffc0000d19fc: 910003e0 mov x0, sp
ffffffc0000d1a00: a90363f7 stp x23, x24, [sp,#48]
ffffffc0000d1a04: a9025bf5 stp x21, x22, [sp,#32]
ffffffc0000d1a08: d2800035 mov x21, #0x1 // #1
ffffffc0000d1a0c: 9272c413 and x19, x0, #0xffffffffffffc000
ffffffc0000d1a10: f9400696 ldr x22, [x20,#8]
ffffffc0000d1a14: 2a1503f7 mov w23, w21
ffffffc0000d1a18: 52800058 mov w24, #0x2 // #2
ffffffc0000d1a1c: f9400a60 ldr x0, [x19,#16]
ffffffc0000d1a20: f9000015 str x21, [x0]
ffffffc0000d1a24: d5033bbf dmb ish
ffffffc0000d1a28: b9401a61 ldr w1, [x19,#24]
ffffffc0000d1a2c: 11000421 add w1, w1, #0x1
ffffffc0000d1a30: b9001a61 str w1, [x19,#24]
ffffffc0000d1a34: f9400a62 ldr x2, [x19,#16]
ffffffc0000d1a38: f9420441 ldr x1, [x2,#1032]
ffffffc0000d1a3c: f85c8020 ldr x0, [x1,#-56]
ffffffc0000d1a40: 37080a60 tbnz w0, #1, ffffffc0000d1b8c <smpboot_thread_fn+0x1a0>
ffffffc0000d1a44: f85c8020 ldr x0, [x1,#-56] // kthread_should_park line
ffffffc0000d1a48: 36100300 tbz w0, #2, ffffffc0000d1aa8 <smpboot_thread_fn+0xbc> // kthread_should_park line
ffffffc0000d1a4c: f900005f str xzr, [x2]
ffffffc0000d1a50: b9401a60 ldr w0, [x19,#24]
it is optimised to 2 instructions ,
this is my patch, hope can be merged :
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 3e6773e..9210030 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -4,6 +4,70 @@
#include <linux/err.h>
#include <linux/sched.h>
+struct kthread {
+ unsigned long flags;
+ unsigned int cpu;
+ void *data;
+ struct completion parked;
+ struct completion exited;
+};
+
+enum KTHREAD_BITS {
+ KTHREAD_IS_PER_CPU = 0,
+ KTHREAD_SHOULD_STOP,
+ KTHREAD_SHOULD_PARK,
+ KTHREAD_IS_PARKED,
+};
+
+#define __to_kthread(vfork) \
+ container_of(vfork, struct kthread, exited)
+
+static inline struct kthread *to_kthread(struct task_struct *k)
+{
+ return __to_kthread(k->vfork_done);
+}
+
+/**
+ * kthread_should_stop - should this kthread return now?
+ *
+ * When someone calls kthread_stop() on your kthread, it will be woken
+ * and this will return true. You should then return, and your return
+ * value will be passed through to kthread_stop().
+ */
+static inline bool kthread_should_stop(void)
+{
+ return test_bit(KTHREAD_SHOULD_STOP, &to_kthread(current)->flags);
+}
+
+/**
+ * kthread_should_park - should this kthread park now?
+ *
+ * When someone calls kthread_park() on your kthread, it will be woken
+ * and this will return true. You should then do the necessary
+ * cleanup and call kthread_parkme()
+ *
+ * Similar to kthread_should_stop(), but this keeps the thread alive
+ * and in a park position. kthread_unpark() "restarts" the thread and
+ * calls the thread function again.
+ */
+static inline bool kthread_should_park(void)
+{
+ return test_bit(KTHREAD_SHOULD_PARK, &to_kthread(current)->flags);
+}
+
+/**
+ * kthread_data - return data value specified on kthread creation
+ * @task: kthread task in question
+ *
+ * Return the data value specified when kthread @task was created.
+ * The caller is responsible for ensuring the validity of @task when
+ * calling this function.
+ */
+static inline void *kthread_data(struct task_struct *task)
+{
+ return to_kthread(task)->data;
+}
+
__printf(4, 5)
struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
void *data,
@@ -39,10 +103,7 @@ struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
void kthread_bind(struct task_struct *k, unsigned int cpu);
int kthread_stop(struct task_struct *k);
-bool kthread_should_stop(void);
-bool kthread_should_park(void);
bool kthread_freezable_should_stop(bool *was_frozen);
-void *kthread_data(struct task_struct *k);
void *probe_kthread_data(struct task_struct *k);
int kthread_park(struct task_struct *k);
void kthread_unpark(struct task_struct *k);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index baf3673..e036019 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -38,29 +38,6 @@ struct kthread_create_info
struct list_head list;
};
-struct kthread {
- unsigned long flags;
- unsigned int cpu;
- void *data;
- struct completion parked;
- struct completion exited;
-};
-
-enum KTHREAD_BITS {
- KTHREAD_IS_PER_CPU = 0,
- KTHREAD_SHOULD_STOP,
- KTHREAD_SHOULD_PARK,
- KTHREAD_IS_PARKED,
-};
-
-#define __to_kthread(vfork) \
- container_of(vfork, struct kthread, exited)
-
-static inline struct kthread *to_kthread(struct task_struct *k)
-{
- return __to_kthread(k->vfork_done);
-}
-
static struct kthread *to_live_kthread(struct task_struct *k)
{
struct completion *vfork = ACCESS_ONCE(k->vfork_done);
@@ -70,36 +47,6 @@ static struct kthread *to_live_kthread(struct task_struct *k)
}
/**
...skipping...
- * When someone calls kthread_stop() on your kthread, it will be woken
- * and this will return true. You should then return, and your return
- * value will be passed through to kthread_stop().
- */
-bool kthread_should_stop(void)
-{
- return test_bit(KTHREAD_SHOULD_STOP, &to_kthread(current)->flags);
-}
-EXPORT_SYMBOL(kthread_should_stop);
-
-/**
- * kthread_should_park - should this kthread park now?
- *
- * When someone calls kthread_park() on your kthread, it will be woken
- * and this will return true. You should then do the necessary
- * cleanup and call kthread_parkme()
- *
- * Similar to kthread_should_stop(), but this keeps the thread alive
- * and in a park position. kthread_unpark() "restarts" the thread and
- * calls the thread function again.
- */
-bool kthread_should_park(void)
-{
- return test_bit(KTHREAD_SHOULD_PARK, &to_kthread(current)->flags);
-}
-EXPORT_SYMBOL_GPL(kthread_should_park);
-
-/**
* kthread_freezable_should_stop - should this freezable kthread return now?
* @was_frozen: optional out parameter, indicates whether %current was frozen
*
@@ -125,19 +72,6 @@ bool kthread_freezable_should_stop(bool *was_frozen)
EXPORT_SYMBOL_GPL(kthread_freezable_should_stop);
/**
- * kthread_data - return data value specified on kthread creation
- * @task: kthread task in question
- *
- * Return the data value specified when kthread @task was created.
- * The caller is responsible for ensuring the validity of @task when
- * calling this function.
- */
-void *kthread_data(struct task_struct *task)
-{
- return to_kthread(task)->data;
-}
-
-/**
* probe_kthread_data - speculative version of kthread_data()
* @task: possible kthread task in question
*
---
(END)
Thanks
--
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/
[toc] | [prev] | [next] | [standalone]
| From | yalin wang <yalin.wang2010@gmail.com> |
|---|---|
| Date | 2015-08-03 04:30 +0200 |
| Message-ID | <pTdFL-60J-1@gated-at.bofh.it> |
| In reply to | #1196574 |
> On Aug 1, 2015, at 21:32, Neil Horman <nhorman@redhat.com> wrote: > > On Sat, Aug 01, 2015 at 03:12:42PM +0800, yalin wang wrote: >> >>> 在 2015年7月31日,22:14,Thomas Gleixner <tglx@linutronix.de> 写道: >>> >>> >>> On Fri, 31 Jul 2015, Thomas Gleixner wrote: >>> >>>> On Fri, 31 Jul 2015, yalin wang wrote: >>>>> it is optimised to 2 instructions , >>>>> >>>>> this is my patch, hope can be merged : >>>> >>>> We are not exposing the internals of kthread management. Period. >>> >>> And your 'optimization' is completely bogus: >>> >>> Before your modification: >>> >>> size kernel/built-in.o >>> >>> text data bss dec hex filename >>> 1091514 141498 341928 1574940 18081c ../build/kernel/built-in.o >>> >>> After: >>> >>> text data bss dec hex filename >>> 1091664 141498 341928 1575090 1808b2 ../build/kernel/built-in.o >>> >>> That's an increase of text size by 150 byte. Interesting optimization. >>> >>> Thanks, >>> >>> tglx >>> >>> >> strange, this is my test result: >> >> size built-in.o* >> text data bss dec hex filename >> 743937 50786 56008 850731 cfb2b built-in.o // with the patch >> 744069 50786 56008 850863 cfbaf built-in.o_old // with out the patch >> > So you're willing to expose the internals of kthread_park in exchange for the > hope of saving 132 bytes of text. > > Thats just dumb. I agree with tglx, this shouldn't change. > > Neil not just size, mainly for performance, without inline: ffffffc0000d26b0: 97fff4aa bl ffffffc0000cf958 <kthread_should_park> ffffffc0000d26b4: 53001c00 uxtb w0, w0 if kthread_should_park() inline: ffffffc0000d1a44: f85c8020 ldr x0, [x1,#-56] // kthread_should_park line ffffffc0000d1a48: 36100300 tbz w0, #2, ffffffc0000d1aa8 <smpboot_thread_fn+0xbc> // kthread_should_park line still use 2 instructions, but don’t need a function call, maybe can do more optimisation by gcc sometimes . Anyway, this is just a suggest, it is up to you apply it or not. :) Thanks -- 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/
[toc] | [prev] | [next] | [standalone]
| From | Jes Sorensen <Jes.Sorensen@redhat.com> |
|---|---|
| Date | 2015-08-03 04:50 +0200 |
| Message-ID | <pTdZ7-6n8-3@gated-at.bofh.it> |
| In reply to | #1198495 |
yalin wang <yalin.wang2010@gmail.com> writes: >> On Aug 1, 2015, at 21:32, Neil Horman <nhorman@redhat.com> wrote: >>> strange, this is my test result: >>> >>> size built-in.o* >>> text data bss dec hex filename >>> 743937 50786 56008 850731 cfb2b built-in.o // with the patch >>> 744069 50786 56008 850863 cfbaf built-in.o_old // with out the >>> patch >>> >> So you're willing to expose the internals of kthread_park in exchange for the >> hope of saving 132 bytes of text. >> >> Thats just dumb. I agree with tglx, this shouldn't change. >> >> Neil > not just size, mainly for performance, > without inline: > > ffffffc0000d26b0: 97fff4aa bl ffffffc0000cf958 <kthread_should_park> > ffffffc0000d26b4: 53001c00 uxtb w0, w0 > > if kthread_should_park() inline: > ffffffc0000d1a44: f85c8020 ldr x0, [x1,#-56] // kthread_should_park > line > ffffffc0000d1a48: 36100300 tbz w0, #2, ffffffc0000d1aa8 > <smpboot_thread_fn+0xbc> // kthread_should_park line > > still use 2 instructions, but don’t need a function call, > maybe can do more optimisation by gcc sometimes . > Anyway, this is just a suggest, > it is up to you apply it or not. :) kthread_park() isn't exactly a performance critical function call. Saving two instructions does not outway the cost of exposing the internals of the kthread API. Jes -- 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/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web