月湖上的黑手——Intel新CPU体验

英特尔在9月5日发布的Lunar Lake芯片包含了很多创新和变革。这些变革吸引了我，让我看到了x86复兴之光。

当我拿到Lunar Lake的真机后，颇为兴奋。

开机后，Windows 11就做了一次升级。升级后，我先看了一下很期待的APX功能，下载windbg，打开一个进程，r命令看寄存器。

结果令我失望，APX新定义的寄存器没有出现，还是老的x64那么多。

根据网上搜索到的信息，2024年秋季发布的新CPU有APX，但是没看到，或许遇到了什么困难吧。

兴奋之余，我想测测新机器的待机能力，把电池充满电后，拔掉电源，打开一个powerpoint文件，截屏做记录。

根据宣传，Lunar Lake的待机能力超强，胜过高通和苹果，可能超过20小时。但让我颇为意外的是，只过了几分钟我再观察时，电量就下降了几个百分点。

我有点不相信自己的眼睛了。为了确认，我2分钟之后再看，没想到只过了2分钟，就又掉了一个百分点，从刚才的93%变成92%了。

或许电量曲线不是线性的，但接下来的观察否定了这个理由。因为过了不到1小时后再看，就只有66%了。

我的兴趣随着电量下降，转身做其它工作了。

大约x个小时后，当我再想起这件事时，新本子已经自动关机下电了。看来电池用光了。

第二天，我想调查一下这个问题。打开任务管理器，按CPU使用时间排名，看到两个微软的服务排在前面。

两个服务中，耗时较多的叫DPS，Diagnostic Policy Service。

上调试器观察DPS，有一个线程很重。

姑且称呼这个线程叫SRUM吧，全称为System Resource Usage Monitor。它看起来在频繁访问本地的数据库（Extensible Storage Engine）。

0:024> k
 # Child-SP          RetAddr               Call Site
00 000000a5`d65fd6c8 00007ffe`4e57af8e     KERNELBASE!ReadFile
01 000000a5`d65fd6d0 00007ffe`4e57ee44     ESENT!ErrorIOMgrIssueIO+0x29e
02 000000a5`d65fd740 00007ffe`4e57cf87     ESENT!IOMgrIssueSyncIO+0x110
03 000000a5`d65fd7e0 00007ffe`4e57cb81     ESENT!COSFile::ErrIOAsync+0x297
04 000000a5`d65fd880 00007ffe`4e57cc76     ESENT!COSFile::ErrIORead+0xc1
05 000000a5`d65fd920 00007ffe`4e597d3a     ESENT!COSFile::ErrIORead+0x1b6
06 000000a5`d65fd9c0 00007ffe`4e59988f     ESENT!LOG_STREAM::ErrLGReadSectorData+0x8a
07 000000a5`d65fda50 00007ffe`4e599c61     ESENT!LOG_READ_BUFFER::ErrReaderEnsureSector+0x13f
08 000000a5`d65fdad0 00007ffe`4e5ef215     ESENT!LOG_READ_BUFFER::ErrLGCheckReadLastLogRecordFF+0x2a1
09 000000a5`d65fe210 00007ffe`4e5ee770     ESENT!LOG::ErrLGSoftStart+0x52d
0a 000000a5`d65fe710 00007ffe`4e5eda59     ESENT!ErrIsamInit+0x2e4
0b 000000a5`d65feb20 00007ffe`4e5ebb66     ESENT!ErrInit+0x331
0c 000000a5`d65fede0 00007ffe`4e5eb658     ESENT!ErrInitComplete+0x10a
0d 000000a5`d65fee40 00007ffe`4e5eb430     ESENT!JetInitEx+0x114
0e 000000a5`d65fef60 00007ffe`4e5eb2de     ESENT!JetInit4W+0x40
0f 000000a5`d65fefb0 00007ffe`41f96cae     ESENT!JetInit3A+0x4e
10 000000a5`d65ff010 00007ffe`41f96b4e     srumsvc!SruDbInitializeJetInstance+0x86
11 000000a5`d65ff0a0 00007ffe`41f85b2d     srumsvc!SruDbStartDatabaseEngine+0x96
12 000000a5`d65ff120 00007ffe`41f854e3     srumsvc!SruTier2StoreGetDbInstance+0x119
13 000000a5`d65ff1a0 00007ffe`41f8e3ac     srumsvc!SruWorkItemQueryStore+0x713
14 000000a5`d65ff560 00007ffe`7d890a8e     srumsvc!SruWorkQueueThreadPoolCallback+0x19c
15 000000a5`d65ff600 00007ffe`7d892241     ntdll!TppWorkpExecuteCallback+0x46e
16 000000a5`d65ff720 00007ffe`7c13dbe7     ntdll!TppWorkerThread+0x801
17 000000a5`d65ffa80 00007ffe`7d8c5a6c     KERNEL32!BaseThreadInitThunk+0x17
18 000000a5`d65ffab0 00000000`00000000     ntdll!RtlUserThreadStart+0x2c

这个线程比较频繁的在响应RPC调用，执行SruQueryStatsFromStore函数。

# Child-SP          RetAddr               Call Site
00 000000a5`d65fd4f8 00007ffe`41f90f7c     srumsvc!SruQueryStatsFromStore
01 000000a5`d65fd500 00007ffe`41f909e6     srumsvc!SruQueryStatsFromStoreByTimeStamp+0x8c
02 000000a5`d65fd5f0 00007ffe`41f90709     srumsvc!CSrumServer::QueryStatisticsInternal+0x132
03 000000a5`d65fd6d0 00007ffe`7c541913     srumsvc!CSrumServer::QueryStatistics+0xb9
04 000000a5`d65fd7b0 00007ffe`7c54618e     RPCRT4!Invoke+0x73
05 000000a5`d65fd820 00007ffe`7c486c80     RPCRT4!Ndr64StubWorker+0x6ee
06 000000a5`d65fde30 00007ffe`7c72872d     RPCRT4!NdrStubCall3+0xc0
07 000000a5`d65fdea0 00007ffe`7c72866b     combase!CStdStubBuffer_Invoke+0x7d [onecore\com\combase\ndr\ndrole\stub.cxx @ 1413] 
08 (Inline Function) --------`--------     combase!InvokeStubWithExceptionPolicyAndTracing::__l6::<lambda_c9f3956a20c9da92a64affc24fdd69ec>::operator()+0x26 [onecore\com\combase\dcomrem\channelb.cxx @ 1152] 
09 000000a5`d65fdee0 00007ffe`7c727be6     combase!ObjectMethodExceptionHandlingAction<<lambda_c9f3956a20c9da92a64affc24fdd69ec> >+0x47 [onecore\com\combase\dcomrem\excepn.hxx @ 94] 
0a (Inline Function) --------`--------     combase!InvokeStubWithExceptionPolicyAndTracing+0x182 [onecore\com\combase\dcomrem\channelb.cxx @ 1150] 
0b 000000a5`d65fdf40 00007ffe`7c727231     combase!DefaultStubInvoke+0x376 [onecore\com\combase\dcomrem\channelb.cxx @ 1219] 
0c (Inline Function) --------`--------     combase!SyncStubCall::Invoke+0x7 [onecore\com\combase\dcomrem\channelb.cxx @ 1276] 
0d (Inline Function) --------`--------     combase!SyncServerCall::StubInvoke+0x35 [onecore\com\combase\dcomrem\ServerCall.hpp @ 790] 
0e 000000a5`d65fe100 00007ffe`7c73c66d     combase!StubInvoke+0x321 [onecore\com\combase\dcomrem\channelb.cxx @ 1485] 
0f 000000a5`d65fe250 00007ffe`7c6d7e3a     combase!ServerCall::ContextInvoke+0x2cd [onecore\com\combase\dcomrem\ctxchnl.cxx @ 1438] 
10 000000a5`d65fe390 00007ffe`7c68217f     combase!DefaultInvokeInApartment+0x8a [onecore\com\combase\dcomrem\callctrl.cxx @ 3246] 
11 000000a5`d65fe3c0 00007ffe`7c67ef23     combase!ComInvokeWithLockAndIPID+0xdaf [onecore\com\combase\dcomrem\channelb.cxx @ 2153] 
12 (Inline Function) --------`--------     combase!ThreadInvokeReturnHresult+0xeb [onecore\com\combase\dcomrem\channelb.cxx @ 6957] 
13 000000a5`d65fe6a0 00007ffe`7c4f3897     combase!ThreadInvoke+0x103 [onecore\com\combase\dcomrem\channelb.cxx @ 7057] 
14 000000a5`d65fe760 00007ffe`7c4a60f4     RPCRT4!DispatchToStubInCNoAvrf+0x17
15 000000a5`d65fe7b0 00007ffe`7c4a6eba     RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x194
16 000000a5`d65fe880 00007ffe`7c4a00b4     RPCRT4!LRPC_SCALL::DispatchRequest+0x85a
17 000000a5`d65fecf0 00007ffe`7c4a463a     RPCRT4!LRPC_SCALL::QueueOrDispatchCall+0xe4
18 000000a5`d65feeb0 00007ffe`7c4aa65c     RPCRT4!LRPC_SCALL::HandleRequest+0x2ba
19 000000a5`d65ff030 00007ffe`7c4a97e3     RPCRT4!LRPC_ADDRESS::HandleRequest+0x3ac
1a 000000a5`d65ff110 00007ffe`7c4a8788     RPCRT4!LRPC_ADDRESS::ProcessIO+0x2f3
1b 000000a5`d65ff480 00007ffe`7d891683     RPCRT4!LrpcIoComplete+0xc8
1c 000000a5`d65ff5a0 00007ffe`7d891fa3     ntdll!TppAlpcpExecuteCallback+0x3b3
1d 000000a5`d65ff720 00007ffe`7c13dbe7     ntdll!TppWorkerThread+0x563
1e 000000a5`d65ffa80 00007ffe`7d8c5a6c     KERNEL32!BaseThreadInitThunk+0x17
1f 000000a5`d65ffab0 00000000`00000000     ntdll!RtlUserThreadStart+0x2c

在调试器下看了这个DPS服务后，我知道电量闪降的原因了。简单说，是糟糕的代码在折腾CPU。

这不禁让我想起发生在几个月前的一次对话。格蠹的办公室在上海的863园区。园区里有很多公司，几年下来，慢慢熟悉了一些公司的人。大约在5月份，园区里的徐总打电话给我，约我喝茶，其实是谈个技术问题。

聊天时我谈到格蠹在做的幽兰代码本，他说有哪些特色，我说超长待机。他接下来的回答很有意思：

“耗不耗电，看上面跑什么。你现在跑Linux，当然省电了，如果跑Windows，一样费电......”

是啊，Windows是越来越让人失望了，昨天在书友群里，一位书友说到Windows升级的问题，引起一大堆共鸣。

看起来，很多书友也都在向Linux转移了。但是这个转移过程涉及到太多问题，是漫长的。

上文说到自动关机时，故意把时间模糊了一下，用了x小时之后的说法。x到底等于几呢，考虑到多层因素，暂且就留个悬念吧。因为写这个文章的主要目的是，各位格友如果买了Lunar Lake，那么记得把DPS服务禁止掉。

(写文章很辛苦，恳请各位读者点击“在看”，也欢迎转发）

*************************************************

正心诚意，格物致知，以人文情怀审视软件，以软件技术改变人生

扫描下方二维码或者在微信中搜索“盛格塾”小程序，可以阅读更多文章和有声读物

也欢迎关注格友公众号