1-- 2-- Copyright 2020 The Android Open Source Project 3-- 4-- Licensed under the Apache License, Version 2.0 (the "License"); 5-- you may not use this file except in compliance with the License. 6-- You may obtain a copy of the License at 7-- 8-- https://www.apache.org/licenses/LICENSE-2.0 9-- 10-- Unless required by applicable law or agreed to in writing, software 11-- distributed under the License is distributed on an "AS IS" BASIS, 12-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 13-- See the License for the specific language governing permissions and 14-- limitations under the License. 15-- 16 17SELECT RUN_METRIC('chrome/chrome_processes.sql'); 18 19-- Grab all the thread tracks which are found in chrome threads. 20DROP VIEW IF EXISTS chrome_track; 21CREATE VIEW chrome_track AS 22 SELECT 23 * 24 FROM thread_track 25 WHERE utid IN (SELECT utid FROM chrome_thread); 26 27-- From all the chrome thread tracks select all the slice details as well as 28-- the utid of the track so we can join with counter table later. 29DROP VIEW IF EXISTS chrome_slice; 30CREATE VIEW chrome_slice AS 31 SELECT 32 slice.*, 33 chrome_track.utid 34 FROM 35 slice JOIN 36 chrome_track ON 37 chrome_track.id = slice.track_id 38 WHERE 39 track_id in (SELECT id FROM chrome_track); 40 41-- Using utid join the thread_counter_track to chrome thread slices. This allows 42-- the filtering of the counter table to only counters associated to these 43-- threads. 44DROP VIEW IF EXISTS chrome_slice_and_counter_track; 45CREATE VIEW chrome_slice_and_counter_track AS 46 SELECT 47 s.*, 48 thread_counter_track.id as counter_track_id, 49 thread_counter_track.name as counter_name 50 FROM 51 chrome_slice s JOIN 52 thread_counter_track ON 53 thread_counter_track.utid = s.utid AND 54 thread_counter_track.name = "thread_time"; 55 56-- Join each slice with the recorded value at the beginning and the end, as 57-- well as computing the total CPU time each slice took. 58-- 59-- We use MIN and MAX inside because sometimes nested slices will have the exact 60-- same timestamp and we need to select one, there is nothing tying a particular 61-- counter value to which slice generated it so we always choose the minimum for 62-- the start on ties and the maximum for ties on the end of the slice. This 63-- means this is always an overestimate, but events being emitted at exactly the 64-- same timestamp is relatively rare so shouldn't cause to much inflation. 65DROP VIEW IF EXISTS chrome_thread_slice_with_cpu_time; 66CREATE VIEW chrome_thread_slice_with_cpu_time AS 67 SELECT 68 end_cpu_time - start_cpu_time AS slice_cpu_time, 69 * 70 FROM ( 71 SELECT 72 s.*, 73 min_counter.start_cpu_time 74 FROM 75 chrome_slice_and_counter_track s LEFT JOIN ( 76 SELECT 77 ts, 78 track_id, 79 MIN(value) AS start_cpu_time 80 FROM counter 81 GROUP BY 1, 2 82 ) min_counter ON 83 min_counter.ts = s.ts AND min_counter.track_id = s.counter_track_id 84 ) min_and_slice LEFT JOIN ( 85 SELECT 86 ts, 87 track_id, 88 MAX(value) AS end_cpu_time 89 FROM counter 90 GROUP BY 1, 2 91 ) max_counter ON 92 max_counter.ts = 93 CASE WHEN min_and_slice.dur >= 0 THEN 94 min_and_slice.ts + min_and_slice.dur 95 ELSE 96 min_and_slice.ts 97 END AND 98 max_counter.track_id = min_and_slice.counter_track_id; 99