* Re: [EDT][PATCH 1/1] msgsnd use freezable blocking call
@ 2015-05-07 7:19 Maninder Singh
0 siblings, 0 replies; 3+ messages in thread
From: Maninder Singh @ 2015-05-07 7:19 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, Vaneet Narang, Rafael J. Wysocki, Peter Zijlstra, yn.gaur
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 2844 bytes --]
EP-F6AA0618C49C4AEDA73BFF1B39950BAB
>On Wed, 06 May 2015 11:29:57 +0000 (GMT) Maninder Singh wrote:
>> EP-F6AA0618C49C4AEDA73BFF1B39950BAB
>>
>> Hi ,
>>
>> Recently shared a patch for using freezable_schedule instead of schedule in msgrcv,
>> and after analysing message queuie implemntation we have realized even msgsnd can also block, if queue is full,
>> So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can schedule function, similar behaviour as msgrcv.
>> This change is applicable for msgsnd as well.
>>
>> we have created patch for remotes/linux-next/akpm, because msgrcv patch is already applied at this branch.
.> so we didnt include
>>
>This changelog is quite poor. It doesn't explain why the change is
>being made, it doesn't explain the user-visible effects which are being
>fixed, etc.
>So I threw it away and copied text from "ipc/msg.c: use freezable
>blocking call":
>One thing which isn't clear to me: *why* do we want to "Avoid waking up
>every thread sleeping in XXX during suspend and resume"? Suspend and
>resume are rare operations. Why do we care if a few threads wake up
>then go to sleep again?
When any task is stuck in Interruptible or Uninterruptible state then waking up of that task fails.
If wakeup fails, then suspend operation fails and all process send to frezeer state at this moment also gets wakeup.
Correct implementation is that if suspend fails, then kernel would retry suspend operation again after some specific timeinterval for some fixed retry count.
But as changes suggested by Mr Colin Cross on LKML https://lkml.org/lkml/2013/5/1/424, for the system calls for which issue has been faced process flag being appended with PF_FREEZER_SKIP.
we are testing some scenerio in which we have to do multi suspend-resume scenario, and we faced the problem thats why suggested the change for msgsnd and msgrcv
Signed-off-by: Vaneet narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Cc: Yogesh Gaur <yn.gaur@samsung.com>
Cc: Manjeet Pawar <manjeet.p@samsung.com>
Cc: Ajeet Yadav <ajeet.y@samsung.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
ipc/msg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call ipc/msg.c
--- a/ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call
+++ a/ipc/msg.c
@@ -673,7 +673,7 @@ long do_msgsnd(int msqid, long mtype, vo
ipc_unlock_object(&msq->q_perm);
rcu_read_unlock();
- schedule();
+ freezable_schedule();
rcu_read_lock();
ipc_lock_object(&msq->q_perm);
_
ÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 3+ messages in thread* [EDT][PATCH 1/1] msgsnd use freezable blocking call
@ 2015-05-06 11:29 Maninder Singh
2015-05-06 22:22 ` Andrew Morton
0 siblings, 1 reply; 3+ messages in thread
From: Maninder Singh @ 2015-05-06 11:29 UTC (permalink / raw)
To: akpm, linux-kernel; +Cc: v.narang
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=windows-1252, Size: 1274 bytes --]
EP-F6AA0618C49C4AEDA73BFF1B39950BAB
Hi ,
Recently shared a patch for using freezable_schedule instead of schedule in msgrcv,
and after analysing message queuie implemntation we have realized even msgsnd can also block, if queue is full,
So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can schedule function, similar behaviour as msgrcv.
This change is applicable for msgsnd as well.
we have created patch for remotes/linux-next/akpm, because msgrcv patch is already applied at this branch.
so we didnt include <linux/freezer.h>
Signed-off-by: Vaneet narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
---
ipc/msg.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ipc/msg.c b/ipc/msg.c
index a7261d5..da5658e 100644
--- a/ipc/msg.c
+++ b/ipc/msg.c
@@ -674,7 +674,7 @@ long do_msgsnd(int msqid, long mtype, void __user *mtext,
ipc_unlock_object(&msq->q_perm);
rcu_read_unlock();
- schedule();
+ freezable_schedule();
rcu_read_lock();
ipc_lock_object(&msq->q_perm);
--
1.7.1
Thanks and Regards,
Maninder Singhÿôèº{.nÇ+·®+%Ëÿ±éݶ\x17¥wÿº{.nÇ+·¥{±þG«éÿ{ayº\x1dÊÚë,j\a¢f£¢·hïêÿêçz_è®\x03(éÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?¨èÚ&£ø§~á¶iOæ¬z·vØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?I¥
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [EDT][PATCH 1/1] msgsnd use freezable blocking call
2015-05-06 11:29 Maninder Singh
@ 2015-05-06 22:22 ` Andrew Morton
0 siblings, 0 replies; 3+ messages in thread
From: Andrew Morton @ 2015-05-06 22:22 UTC (permalink / raw)
To: maninder1.s; +Cc: linux-kernel, v.narang, Rafael J. Wysocki, Peter Zijlstra
On Wed, 06 May 2015 11:29:57 +0000 (GMT) Maninder Singh <maninder1.s@samsung.com> wrote:
> EP-F6AA0618C49C4AEDA73BFF1B39950BAB
>
> Hi ,
>
> Recently shared a patch for using freezable_schedule instead of schedule in msgrcv,
> and after analysing message queuie implemntation we have realized even msgsnd can also block, if queue is full,
> So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can schedule function, similar behaviour as msgrcv.
> This change is applicable for msgsnd as well.
>
> we have created patch for remotes/linux-next/akpm, because msgrcv patch is already applied at this branch.
> so we didnt include <linux/freezer.h>
>
This changelog is quite poor. It doesn't explain why the change is
being made, it doesn't explain the user-visible effects which are being
fixed, etc.
So I threw it away and copied text from "ipc/msg.c: use freezable
blocking call":
One thing which isn't clear to me: *why* do we want to "Avoid waking up
every thread sleeping in XXX during suspend and resume"? Suspend and
resume are rare operations. Why do we care if a few threads wake up
then go to sleep again?
From: Maninder Singh <maninder1.s@samsung.com>
Subject: ipc/msg.c: msgsnd: use freezable blocking call
Avoid waking up every thread sleeping in a msgsnd call during suspend and
resume by calling a freezable blocking call. Previous patches modified
the freezer to avoid sending wakeups to threads that are blocked in
freezable blocking calls.
This call was selected to be converted to a freezable call because it
doesn't hold any locks or release any resources when interrupted that
might be needed by another freezing task or a kernel driver during
suspend, and is a common site where idle userspace tasks are blocked.
Signed-off-by: Vaneet narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Cc: Yogesh Gaur <yn.gaur@samsung.com>
Cc: Manjeet Pawar <manjeet.p@samsung.com>
Cc: Ajeet Yadav <ajeet.y@samsung.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
ipc/msg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call ipc/msg.c
--- a/ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call
+++ a/ipc/msg.c
@@ -673,7 +673,7 @@ long do_msgsnd(int msqid, long mtype, vo
ipc_unlock_object(&msq->q_perm);
rcu_read_unlock();
- schedule();
+ freezable_schedule();
rcu_read_lock();
ipc_lock_object(&msq->q_perm);
_
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-05-07 7:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-07 7:19 [EDT][PATCH 1/1] msgsnd use freezable blocking call Maninder Singh
-- strict thread matches above, loose matches on Subject: below --
2015-05-06 11:29 Maninder Singh
2015-05-06 22:22 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®