[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <tencent_18C611757FED8D54331785FA@qq.com>
Date: Thu, 27 Feb 2025 02:07:57 +0800
From: "Wentao Guan" <guanwentao@...ontech.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>, "王昱力" <wangyuli@...ontech.com>
Cc: "rafael" <rafael@...nel.org>, "pavel" <pavel@...nel.org>, "tglx" <tglx@...utronix.de>, "mingo" <mingo@...hat.com>, "bp" <bp@...en8.de>, "dave.hansen" <dave.hansen@...ux.intel.com>, "x86" <x86@...nel.org>, "hpa" <hpa@...or.com>, "linux-pm" <linux-pm@...r.kernel.org>, "linux-kernel" <linux-kernel@...r.kernel.org>, "占俊" <zhanjun@...ontech.com>, "聂诚" <niecheng1@...ontech.com>, "陈麟轩" <chenlinxuan@...ontech.com>, "Huacai Chen" <chenhuacai@...ngson.cn>
Subject: Re: [RFC PATCH] x86 / hibernate: Eliminate the redundant smp_ops.play_dead assignment
Hello,
Thanks for your reply.
In my opinion, the only logic different before the patch is delete smp_ops.play_dead
save and restore, as the comment "the resumed kernel will decide itself" and same
logic as which in arch/arm64/kernel/hibernate.c, the ok path will work as expect.
When discussing the error path and ret value that we not restore play_dead,
I will try to analyze the difference between native_play_dead and resume_play_dead,
and sev_es_play_dead [the all possiable three value], and I see some mwait and hlt
way difference.[maybe it happens as disable the cpu failed and goes to Enable_cpus
path in func:resume_target_kernel in hibernate.c? ] Is that it desgin to do and we can
move it to a common place in hibernate.c and left some comments ?
BRs
Wentao Guan
Powered by blists - more mailing lists