CN113760374B - Binding method and device of processor and electronic equipment - Google Patents

Binding method and device of processor and electronic equipment Download PDF

Info

Publication number
CN113760374B
CN113760374B CN202111002197.9A CN202111002197A CN113760374B CN 113760374 B CN113760374 B CN 113760374B CN 202111002197 A CN202111002197 A CN 202111002197A CN 113760374 B CN113760374 B CN 113760374B
Authority
CN
China
Prior art keywords
binding
layer
binding core
core
service unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111002197.9A
Other languages
Chinese (zh)
Other versions
CN113760374A (en
Inventor
闫森
胡自健
王洪烛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hisense Electronic Technology Shenzhen Co ltd
Original Assignee
Hisense Electronic Technology Shenzhen Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hisense Electronic Technology Shenzhen Co ltd filed Critical Hisense Electronic Technology Shenzhen Co ltd
Priority to CN202111002197.9A priority Critical patent/CN113760374B/en
Publication of CN113760374A publication Critical patent/CN113760374A/en
Application granted granted Critical
Publication of CN113760374B publication Critical patent/CN113760374B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/50Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4403Processor initialisation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/545Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02DCLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

The application relates to the technical field of computers, and relates to a binding method and device of a processor and electronic equipment, wherein the method comprises the following steps: the system software architecture of the intelligent terminal comprises an application program layer, a system framework layer, a hardware abstraction layer and a Linux kernel layer from top to bottom, and the system software architecture responds to a binding core request triggered by the application program layer or the system framework layer, and sends the binding core request to a binding core service unit, wherein the binding core request comprises a service unit identifier needing to carry out binding core operation; acquiring hardware parameters of a Linux kernel layer by a binding core service unit, and determining at least one processor with a binding core relation of an application program corresponding to a service unit identifier according to the hardware parameters; notifying the Linux kernel layer of the binding relation by a binding service unit; in this way, in response to the hardware call requirement of the application program, the Linux kernel layer calls at least one processor according to the binding relation, so that the running efficiency of the application program is met, and the response speed is improved.

Description

Binding method and device of processor and electronic equipment
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a binding method and apparatus for a processor, and an electronic device.
Background
Android (Android) is an operating system that is open source code according to Lin Nake s (Linux) real-time operating system (kernel), which does not contain commercial operating system (GNU) components, and is mainly used in mobile smart devices. In the prior art, the allocation of the central processing unit (Central Processing Unit, CPU) core is controlled by the bottom layer kernel by default, and the bottom layer kernel generally adopts a general CPU core scheduling policy to implement scheduling management on the process.
For example, the bottom layer kernel distributes CPU cores for each service request in the system one by one according to the receiving time sequence of the service request so as to realize process scheduling; for another example, the bottom layer kernel allocates CPU cores for each service request in turn according to the preset priority of each service request, so as to implement process scheduling.
In general, the default scheduling policy adopted by the android operating system can meet the requirement of the existing process scheduling. However, when a process that a certain service request needs to be invoked requires higher operation efficiency, and the CPU core pre-allocated to the lower layer kernel cannot meet the operation efficiency of the invoked process, the phenomena of blocking, crashing and the like of an application program corresponding to the process can be caused. However, in the prior art, there is no preferred solution to the problem that the above-mentioned pre-allocated CPU cannot meet the running efficiency required by the process.
In summary, a new method is needed to solve the above-mentioned problems.
Disclosure of Invention
The embodiment of the application provides a binding method and device of a processor and electronic equipment, which are used for solving the problem that a CPU (Central processing Unit) pre-allocated by a bottom kernel cannot meet the running efficiency required by a process in the prior art.
The specific technical scheme provided by the application is as follows:
in a first aspect, an embodiment of the present application provides a binding method of a processor, where the method is applied to an intelligent terminal, and a system software architecture of the intelligent terminal includes an application layer, a system framework layer, a hardware abstraction layer, and a Linux kernel layer from top to bottom, where the method includes:
responding to a binding core request triggered by the application program layer or the system framework layer, and sending the binding core request to a binding core service unit, wherein the binding core request comprises a service unit identifier which needs to carry out binding core operation;
acquiring hardware parameters of the Linux kernel layer by the kernel binding service unit, and determining at least one processor with a kernel binding relation of an application program corresponding to the service unit identifier according to the hardware parameters;
notifying the Linux kernel layer of the binding relation by the binding service unit;
And responding to the hardware call requirement of the application program, and calling the at least one processor by the Linux kernel layer according to the binding relation.
In some possible embodiments, the application layer triggering the binding core request includes:
triggering the binding core request through the application program layer if the running state of the application program corresponding to the service unit identifier meets a first preset condition;
the system framework layer triggers the binding core request, including:
and if the system framework layer monitors the progress meeting the second preset condition, triggering the core binding request through the system framework layer.
In some possible embodiments, the first preset condition includes that the required resource amount of the application program corresponding to the service unit identifier exceeds a first threshold, and/or the total number of processes included in the application program corresponding to the service unit identifier reaches a second threshold;
the second preset condition includes that the running speed corresponding to the existing process and/or the existing thread is lower than a third threshold value, and/or the Activity cold start needs to be created.
In some possible embodiments, the sending the binding core request to a binding core service unit includes:
Invoking a first binding core service interface contained in the application program layer or invoking a second binding core service interface contained in the system framework layer, and sending the binding core request to the binding core service unit;
the method for acquiring the hardware parameters of the Linux kernel layer by the binding core service unit comprises the following steps:
calling a third binding core service interface contained in the binding core service unit, and sending an acquisition request to the hardware abstraction layer, wherein the acquisition request is used for acquiring hardware parameters of the Linux kernel layer;
according to the acquisition request, a fourth binding core service interface contained in the hardware abstraction layer is called, the hardware parameters of the Linux kernel layer are acquired, and the fourth binding core service interface is called and sent to the third binding core service interface;
and the core binding service unit receives the hardware parameters through the third core binding service interface.
In some possible embodiments, the determining, according to the hardware parameter, that the application corresponding to the service unit identifier has a binding relation includes:
acquiring a preset binding core relation set by the binding core service unit, wherein the binding core relation set comprises all service unit identifiers conforming to preset conditions and at least one processor with a binding core relation of each corresponding application program;
And screening out the binding core relation associated with the application program corresponding to the service unit identifier from the binding core relation set according to the hardware parameters, and determining the at least one processor corresponding to the application program according to the binding core relation.
In some possible embodiments, the notifying, by the binding core service unit, the Linux kernel layer of the binding relation includes:
calling a third binding core service interface contained in the binding core service unit, and sending the binding core relation to a fourth binding core service interface of the hardware abstraction layer;
and calling a fourth binding core service interface contained in the hardware abstraction layer, and sending the binding core relation to the Linux kernel layer.
In some possible embodiments, before the sending of the binding core request to the binding core service unit in response to the binding core request triggered by the application layer or the system frame layer, the method further includes:
calling an init daemon by the Linux kernel layer to obtain a configuration file corresponding to the binding service;
and analyzing the configuration file, loading and initializing the binding core service unit.
In some possible embodiments, parsing the configuration file, loading and initializing the binding core service unit includes:
Analyzing the configuration file, and executing an initialization CPU parameter process through the hardware abstraction layer to obtain hardware parameters of the Linux kernel layer;
and calling the hardware abstraction layer to register the service type with the HwServiceManager, and registering the service type communicated with the core binding service unit as the Hwbinder service type.
In a second aspect, an embodiment of the present application provides a binding apparatus for a processor, including:
the sending module is used for responding to a binding core request triggered by the application program layer or the system framework layer, sending the binding core request to a binding core service unit, wherein the binding core request comprises a service unit identifier which needs to carry out binding core operation;
the determining module is used for acquiring the hardware parameters of the Linux kernel layer by the binding service unit, and determining at least one processor with a binding relation of an application program corresponding to the service unit identifier according to the hardware parameters;
the notification module is used for notifying the Linux kernel layer of the binding relation by the binding service unit;
and the calling module is used for responding to the hardware calling requirement of the application program, and the Linux kernel layer calls the at least one processor according to the binding relation.
In some possible embodiments, the application layer triggers the binding core request, and the sending module is configured to:
triggering the binding core request through the application program layer if the running state of the application program corresponding to the service unit identifier meets a first preset condition;
the system framework layer triggers the binding core request, and the sending module is configured to:
and if the system framework layer monitors the progress meeting the second preset condition, triggering the core binding request through the system framework layer.
In some possible embodiments, the first preset condition includes that the required resource amount of the application program corresponding to the service unit identifier exceeds a first threshold, and/or the total number of processes included in the application program corresponding to the service unit identifier reaches a second threshold;
the second preset condition includes that the running speed corresponding to the existing process and/or the existing thread is lower than a third threshold value, and/or the Activity cold start needs to be created.
In some possible embodiments, the sending the binding core request to a binding core service unit, the sending module is configured to:
invoking a first binding core service interface contained in the application program layer or invoking a second binding core service interface contained in the system framework layer, and sending the binding core request to the binding core service unit;
The hardware parameters of the Linux kernel layer are acquired by the kernel binding service unit, and the determining module is used for:
calling a third binding core service interface contained in the binding core service unit, and sending an acquisition request to the hardware abstraction layer, wherein the acquisition request is used for acquiring hardware parameters of the Linux kernel layer;
according to the acquisition request, a fourth binding core service interface contained in the hardware abstraction layer is called, the hardware parameters of the Linux kernel layer are acquired, and the fourth binding core service interface is called and sent to the third binding core service interface;
and the core binding service unit receives the hardware parameters through the third core binding service interface.
In some possible embodiments, the determining module is configured to determine, according to the hardware parameter, that the application corresponding to the service unit identifier has a binding relationship, where the determining module is configured to:
acquiring a preset binding core relation set by the binding core service unit, wherein the binding core relation set comprises all service unit identifiers conforming to preset conditions and at least one processor with a binding core relation of each corresponding application program;
and screening out the binding core relation associated with the application program corresponding to the service unit identifier from the binding core relation set according to the hardware parameters, and determining the at least one processor corresponding to the application program according to the binding core relation.
In some possible embodiments, the notifying, by the binding core service unit, the binding core relationship to the Linux kernel layer, and the notifying module is configured to:
calling a third binding core service interface contained in the binding core service unit, and sending the binding core relation to a fourth binding core service interface of the hardware abstraction layer;
and calling a fourth binding core service interface contained in the hardware abstraction layer, and sending the binding core relation to the Linux kernel layer.
In some possible embodiments, before the sending of the binding core request to the binding core service unit in response to the binding core request triggered by the application layer or the system frame layer, the sending module is further configured to:
calling an init daemon by the Linux kernel layer to obtain a configuration file corresponding to the binding service;
and analyzing the configuration file, loading and initializing the binding core service unit.
In some possible embodiments, the configuration file is parsed, the binding core service unit is loaded and initialized, and the sending module is configured to:
analyzing the configuration file, and executing an initialization CPU parameter process through the hardware abstraction layer to obtain hardware parameters of the Linux kernel layer;
And calling the hardware abstraction layer to register the service type with the HwServiceManager, and registering the service type communicated with the core binding service unit as the Hwbinder service type.
In a third aspect, an embodiment of the present application provides an electronic device, including:
a memory for storing a computer program executable by the controller;
a controller is coupled to the memory and configured to perform the method of any of the first aspects described above.
In a fourth aspect, embodiments of the present application provide a computer-readable storage medium, which when executed by a processor, causes the processor to perform the method of any one of the first aspects.
In summary, in this embodiment of the present application, the intelligent terminal may send a binding request to the binding service unit in response to a binding request triggered by an application layer or a system framework layer, and the binding service unit determines, according to the obtained hardware parameter of the Linux kernel layer, at least one processor having a binding relationship with an application corresponding to a service unit identifier, and then the binding service unit notifies the Linux kernel layer of the binding relationship, and in response to a hardware call requirement of the application, the Linux kernel layer may call the at least one processor according to the binding relationship; in this way, the binding core service unit determines the binding core relation more in line with the requirement of the binding core request according to the acquired hardware parameters of the Linux kernel layer, and notifies the Linux kernel layer of the binding core relation, so that the degree of freedom and convenience of development in an application program layer and a system frame layer are improved; because the system software architecture adopts a layered architecture, migration adaptation can be rapidly carried out on different hardware platforms, and the complexity of transplanting is greatly reduced; meanwhile, in the embodiment of the application, through the core binding service unit, the core binding can be performed for the application program in a targeted manner according to the characteristics of different performance scenes, so that the running efficiency of the application program is met, and the response speed of the intelligent terminal is improved.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments of the present application will be briefly described below, and it is obvious that the drawings that are described below are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic diagram of a system software architecture of an intelligent terminal in an embodiment of the present application;
FIG. 2 is a schematic diagram of an initialization process of a system software architecture according to an embodiment of the present application;
FIG. 3 is a schematic diagram of initializing a system software architecture according to an embodiment of the present application;
FIG. 4 is a schematic diagram of initialization of a system software architecture according to an embodiment of the present application;
FIG. 5 is a schematic flow chart of binding of a processor in the embodiment of the present application;
FIG. 6 is a flowchart of acquiring hardware parameters of a Linux kernel layer according to an embodiment of the present application;
fig. 7 is a schematic diagram of an application scenario for obtaining hardware parameters of a Linux kernel layer in an embodiment of the present application;
FIG. 8 is a schematic diagram of an application scenario for obtaining hardware parameters of a Linux kernel layer in an embodiment of the present application;
FIG. 9 is a schematic flow chart of determining a binding relationship in an embodiment of the present application;
FIG. 10 is a flowchart illustrating a process for implementing processor binding according to an embodiment of the present application;
FIG. 11 is a schematic diagram illustrating an inter-binding service interface call according to an embodiment of the present application;
FIG. 12 is a schematic diagram of an embodiment of the present application;
FIG. 13 is a schematic diagram of a logic architecture of a binding device of a processor according to an embodiment of the present application;
fig. 14 is a schematic diagram of an entity architecture of an electronic device according to an embodiment of the present application.
Detailed Description
In order to enable those skilled in the art to better understand the technical solutions of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.
It should be noted that the terms "first," "second," and the like in the description and in the claims are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that embodiments of the present application described herein may be implemented in sequences other than those illustrated or otherwise described herein. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present application as detailed in the accompanying claims.
In order to solve the problem that the CPU (Central processing Unit) pre-allocated by the bottom kernel in the prior art cannot meet the running efficiency required by the process, in the embodiment of the application, the binding request can be sent to the binding service unit in response to the binding request triggered by the application program layer or the system framework layer, the binding service unit determines at least one processor with the binding relation of the application program corresponding to the service unit identifier according to the acquired hardware parameters of the Linux kernel layer, and then the binding service unit notifies the Linux kernel layer of the binding relation, so that in response to the hardware calling requirement of the application program, the Linux kernel layer can call the at least one processor according to the binding relation, thereby meeting the running efficiency of the application program and improving the response speed of the intelligent terminal.
In the embodiment of the application, the intelligent terminal may be an intelligent mobile terminal, a tablet computer, a notebook computer, an intelligent palm device, a personal computer (Personal Computer, PC), a computer, an intelligent screen, various wearable devices, a personal digital assistant (Personal Digital Assistant, PDA), or the like. Nor is it limiting in this application.
The preferred embodiments of the present application will be described in detail below with reference to the attached drawings, it should be understood that the preferred embodiments described herein are for illustration and explanation of the present application only, and are not intended to limit the present application, and the features of the embodiments and examples of the present application may be combined with each other without conflict.
Fig. 1 shows a schematic diagram of a system software architecture of an intelligent terminal. Referring to fig. 1, in the embodiment of the present Application, an android system software architecture 100 of an intelligent terminal includes an Application (APP) layer 101, a system Framework (Framework) layer 102, a Hardware Abstraction (HAL) layer 103, and a Linux Kernel (Kernel) layer 104 from top to bottom.
In the embodiment of the present application, a development code for the kernel-binding service unit 105 is embedded in an android system native software architecture, a kernel-binding service interface is obtained by encapsulating a bottom interface included in the Linux kernel layer 104, and a kernel-binding request depth adaptation triggered by the application program layer 101 or the system framework layer 102 is implemented by calling the kernel-binding service interface, so that a core scheduling policy which is relatively smoother and more appropriate in matching is implemented according to different performance scenarios.
In this embodiment, referring to fig. 2, during initialization of the android system, the binding core service unit is loaded and initialized by executing the following steps:
step 200: and calling an init daemon by the Linux kernel layer to obtain a configuration file corresponding to the binding service.
In this embodiment, when the android system of the intelligent terminal is booted and started by the Boot Loader, specifically, when the intelligent terminal is in a Power-off state, the Boot chip starts to execute from a preset code solidified in a Read-Only Memory (ROM) by a user pressing a Power key for a long time, and loads a Boot program to a Random-access processor (RAM) to initialize hardware parameters and the like.
Then, the Linux kernel is started, an init.rc file is obtained from the system file, and an init daemon is called to obtain a configuration file corresponding to the binding core service.
Step 210: and analyzing the configuration file, loading and initializing the binding core service unit.
In the embodiment of the present application, when executing step 210, firstly, the configuration file is parsed, and the hardware parameters of the Linux kernel layer are obtained by executing the process of initializing the CPU parameters through the hardware abstraction layer; then, the hardware abstraction layer is called to register the service type with the HwServiceManager, and the service type communicated with the binding core service unit is registered as the Hwbinder service type.
Optionally, referring to fig. 1, when step 210 is executed, the Linux kernel layer 104 invokes an init daemon to parse the configuration file, develops a section of code on the hardware abstraction layer 103 in the android system native software architecture, configures the fourth binding core service interface 109, and implements the function of invoking the fourth binding core service interface 109 to obtain the hardware parameters of the Linux kernel layer 104; then, a kernel-binding Service unit 105 is loaded and initialized, where the kernel-binding Service unit (Turbo Service) 105 is configured to obtain, according to a kernel-binding request triggered by the application layer 101 or the system framework layer 102, a hardware parameter of the Linux kernel layer 104, determine, according to the hardware parameter, at least one processor having a kernel-binding relationship with an application program corresponding to a Service unit identifier included in the kernel-binding request, and notify the Linux kernel layer 104 of the kernel-binding relationship, so that when the hardware call requirement of the application program is responded, the Linux kernel layer 104 calls the at least one processor according to the kernel-binding relationship, thereby implementing corresponding deep adaptation.
In this embodiment, when the binding core service unit is loaded and initialized, the third binding core service interface 108 is configured, then, a corresponding code is developed on the system framework layer 102, and the second binding core service interface 107 is configured, so that the function of sending the binding core request triggered by the system framework layer 102 to the binding core service unit 105 by calling the second binding core service interface 107 is realized, and thus, the performance optimization and the deep adaptation in the android system native software architecture are realized by triggering the set of binding core service interfaces.
Correspondingly, a section of code is developed on the application program layer, and the first binding core service interface 106 is configured, so that the function of sending the binding core request triggered by the application program layer 101 to the binding core service unit 105 by calling the first binding core service interface 106 is realized, and the performance optimization and the depth adaptation in the android system native software architecture are realized by triggering the set of binding core service interfaces.
For example, referring to FIG. 3, a hardware abstraction layer (Turbo HAL) initialization is used as an example.
In the embodiment of the application, the Turbo HAL process is an independent HAL layer process, and provides services to an upper layer according to a hidl frame in a native software architecture of an android system.
Optionally, the Turbo HAL process is called by parsing a corresponding configuration file (e.g., rc file) in the init boot process, and is a native daemon.
Specifically, the hardware parameters of the Linux kernel layer are obtained by analyzing the configuration file and executing the process of initializing the CPU parameters by the Turbo HAL process.
Optionally, in the embodiment of the present application, an initcpupaas method of cpuhhalmanager may be used to execute an initialization CPU parameter process to obtain a hardware parameter of the Linux kernel layer, where the initialization CPU parameter process includes core number compatibility, size core, frequency judgment, and the like.
Then, the Turbo HAL process is called to register the service type with the HwServiceManager, and the service type communicated with the binding core service unit is registered as the Hwbinder service type.
Optionally, in the embodiment of the present application, the above registration service type may be implemented by using a registerAsService method, and registers to the hwservicemanager as a real-name hwbinder service, so that a Hardware Abstraction (HAL) layer process may have a capability of providing a binding core service across processes.
For another example, referring to fig. 4, a bound core Service unit (Turbo Service) initialization is taken as an example.
In this embodiment of the present application, the Turbo Service process is a process of an independent kernel-binding Service unit, and has a system uid, which is a core of a java layer kernel-binding Service, and is configured to provide the kernel-binding Service for a system frame layer process (such as a system_server process) or an application program layer (Turbo HAL) process.
In a startother Service method of the system server startup procedure, a Service startup auxiliary system servicemanager in a native system architecture of an android system is used to start a kernel-binding Service unit (Turbo Service) to obtain a Turbo Service binder proxy.
Alternatively, in the embodiment of the present application, the startup manner may use a binderdevice, that is, an anonymous binder service. Since the core Service capability of the core Service unit (Turbo Service) is supported by the hardware abstraction layer (Turbo HAL) process, the core Service proxy of the hardware abstraction layer (Turbo HAL) can be obtained through the aforesaid start-up initialization.
In the embodiment of the application, after the binding core service unit obtains the binding core service agent of the hardware abstraction layer, the application program layer can realize inter-process communication with the binding core service unit by calling the corresponding first binding core service interface.
In the embodiment of the present application, since the application layer embeds the Turbo lib jar (SDK) packet, the application layer may perform inter-process communication with the bound core Service unit (Turbo Service) through the SDK jar packet by using the aidl.
In this embodiment of the present application, the obtained Turbo Service binder agent is maintained and used by the turbosupporthelter tool class, so that when the system framework invokes the second binding core interface included in the second binding core interface, the second binding core interface may be encapsulated by the turbosupporthelter tool class.
Referring to fig. 5, in the embodiment of the present application, a specific process of binding a processor by using an intelligent terminal is provided as follows:
step 500: and responding to a binding core request triggered by an application program layer or a system framework layer, and sending the binding core request to a binding core service unit, wherein the binding core request comprises a service unit identifier which needs to carry out binding core operation.
In this embodiment of the present application, the layers sent according to the binding core request are different, including but not limited to the following two cases:
in the first case, if the running state of the application program corresponding to the service unit identifier meets a first preset condition, triggering the binding core request through an application program layer; the first preset condition includes that the required resource amount of the application program corresponding to the service unit identifier exceeds a first threshold value, and/or the total number of processes contained in the application program corresponding to the service unit identifier reaches a second threshold value.
Then, in the embodiment of the application, after receiving a binding core request triggered by an application program layer, the intelligent terminal responds to the binding core request, and calls a first binding core service interface included in the application program layer to send the binding core request to a binding core service unit, so that the binding core service unit calls a third binding core interface to acquire hardware parameters of a Linux kernel layer. And determining at least one corresponding processor according to the acquired hardware parameters.
For example, assume that the service unit identifies that the corresponding application contains up to 6 total processes, and that the first threshold is 7.
Then, the intelligent terminal determines that the running state of the application program corresponding to the service unit identifier meets a first preset condition, the application program layer triggers a core binding request, and then, the intelligent terminal calls a first core binding service interface contained in the application program layer in response to the core binding request triggered by the application program layer, and sends the core binding request to the core binding service unit.
In the second case, in the embodiment of the present application, if the system frame layer monitors a process that meets the second preset condition, the system frame layer triggers a binding core request; the second preset condition includes that the running speed corresponding to the existing process and/or the existing thread is lower than a third threshold value, and/or the Activity cold start needs to be created.
Then, in the embodiment of the application, after receiving a binding core request triggered by a system framework layer, the intelligent terminal responds to the binding core request, and calls a second binding core service interface included in the system framework layer to send the binding core request to a binding core service unit, so that the binding core service unit calls a third binding core interface to acquire hardware parameters of a Linux kernel layer. And determining at least one corresponding processor according to the acquired hardware parameters.
For example, assume that it is monitored by the system framework layer that a new process needs to be created for an Activity cold start.
Then, the intelligent terminal determines that the system frame layer monitors the progress meeting the second preset condition, the system frame layer triggers a core binding request, and then, the intelligent terminal responds to the core binding request triggered by the system frame layer, calls a second core binding service interface contained in the system frame layer, and sends the core binding request to a core binding service unit.
Step 510: and acquiring hardware parameters of the Linux kernel layer by the kernel binding service unit.
In this embodiment, referring to fig. 6, when step 510 is performed, the hardware parameters of the Linux kernel layer may be obtained by performing the following steps:
step 5101: and calling a third binding core service interface contained in the binding core service unit, and sending an acquisition request to the hardware abstraction layer, wherein the acquisition request is used for acquiring hardware parameters of the Linux kernel layer.
In this embodiment of the present application, an acquisition request for acquiring a hardware parameter of a Linux kernel layer is sent to a hardware abstraction layer (i.e., turbo HAL) by calling a second binding Service interface included in a binding Service unit (i.e., turbo Service).
Step 5102: and according to the acquisition request, calling a fourth binding core service interface contained in the hardware abstraction layer, acquiring hardware parameters of the Linux kernel layer, and calling the fourth binding core service interface to send to the third binding core service interface.
In this embodiment, when step 5102 is executed, according to each preset binding core service interface, a fourth binding core service interface included in the hardware abstraction layer is called to obtain a hardware parameter of the Linux kernel layer, and then, the fourth binding core service interface included in the hardware abstraction layer is called to send the obtained hardware parameter of the Linux kernel layer to the third binding core service interface.
Step 5103: the binding core service unit receives the hardware parameters through the third binding core service interface.
In this embodiment of the present application, the binding core service unit receives, through the included third binding core service interface, the hardware parameter of the Linux kernel layer, so as to execute step 520, and determine at least one processor having a binding relation with the application program corresponding to the service unit identifier included in the binding core request.
For example, referring to FIG. 7, an application layer triggers a bind core request.
Assume that the service unit identifies that the amount of required resources of the corresponding application a exceeds a first threshold.
The application program layer triggers a binding core request, and the intelligent terminal responds to the binding core request triggered by the application program layer, calls a first binding core service interface contained in the application program layer and sends the binding core request to a binding core service unit.
And then, after receiving the binding request, the binding service unit calls a third binding service interface contained in the binding service unit and sends an acquisition request for acquiring the hardware parameters of the Linux kernel layer to the hardware abstraction layer.
Correspondingly, the hardware abstraction layer calls a corresponding fourth binding core service interface according to the acquisition request to acquire the hardware parameters of the Linux kernel layer, and calls the fourth binding core service interface to send the hardware parameters to the third binding core service interface, so that the binding core service unit receives the hardware parameters through the third binding core service interface.
For another example, referring to fig. 8, a system framework layer triggers a binding core request.
Assume that the system framework layer monitors that a corresponding process needs to be created for an Activity cold start.
The system framework layer triggers a binding core request, and the intelligent terminal responds to the binding core request triggered by the system framework layer and calls a second binding core service interface contained in the system framework layer to send the binding core request to the binding core service unit.
And then, after receiving the binding request, the binding service unit calls a third binding service interface contained in the binding service unit and sends an acquisition request for acquiring the hardware parameters of the Linux kernel layer to the hardware abstraction layer.
Correspondingly, the hardware abstraction layer calls a corresponding fourth binding core service interface according to the acquisition request to acquire the hardware parameters of the Linux kernel layer, and calls the fourth binding core service interface to send the hardware parameters to the third binding core service interface, so that the binding core service unit receives the hardware parameters through the third binding core service interface.
Step 520: and determining at least one processor with a binding relation with the application program corresponding to the service unit identifier according to the hardware parameters.
In this embodiment, referring to fig. 9, when step 520 is performed, it may be determined that at least one processor having a binding relationship with an application corresponding to a service unit identifier by performing steps 5201-5202:
step 5201: the method comprises the steps that a preset binding core relation set is obtained by a binding core service unit, wherein the binding core relation set comprises all service unit identifiers conforming to preset conditions and at least one processor with a binding core relation of application programs corresponding to the service unit identifiers.
In the embodiment of the application, when the software architecture of the android system is initialized, a preset binding core relation set can be stored in the local memory of the binding core service unit; then, when step 5201 is executed, the preset set of binding core relationships is obtained by the binding core service unit.
Optionally, when the software architecture of the android system is initialized, a preset binding core relation set may be stored in a database associated with the binding core service unit.
Step 5202: and screening out the binding core relation associated with the application program corresponding to the service unit identifier from the binding core relation set according to the hardware parameters, and determining at least one processor corresponding to the application program according to the binding core relation.
In this embodiment of the present application, after executing step 510, the binding core service unit obtains the hardware parameter of the corresponding Linux kernel layer, and when executing step 5202, according to the hardware parameter, the binding core relationship associated with the application program corresponding to the service unit identifier included in the binding core request is screened out from the binding core relationship set obtained after executing step 5201, and according to the binding core relationship, at least one processor corresponding to the application program is determined.
Step 530: and the binding core service unit informs the Linux kernel layer of the binding core relation.
In this embodiment, referring to fig. 10, when step 530 is performed, the Linux kernel layer may be notified of the obtained binding relationship by performing the following steps:
step 5301: and calling a third binding core service interface contained in the binding core service unit, and sending the binding core relation to a fourth binding core service interface of the hardware abstraction layer.
In this embodiment, when step 520 is executed, it is determined that at least one processor having a binding relationship with an application corresponding to a service unit identifier, and when step 5301 is executed, a third binding service interface included in a binding service unit is called, and the binding relationship is sent to a fourth binding service interface included in a hardware abstraction layer.
Step 5302: and calling a fourth binding core service interface contained in the hardware abstraction layer, and sending the binding core relation to the Linux kernel layer.
In this embodiment, when step 5302 is executed, a fourth binding core service interface included in the hardware abstraction layer is called, and the binding core relationship is sent to the Linux kernel layer, so that when a hardware call requirement of an application program corresponding to a service unit identifier included in a binding core request is responded, at least one processor corresponding to the binding core relationship is called by the Linux kernel layer according to the binding core relationship.
Step 540: and in response to the hardware call requirement of the application program, invoking at least one processor according to the binding relation by the Linux kernel layer.
According to the embodiment of the application program, according to the binding core relation, when the hardware call requirement of the application program corresponding to the service unit identifier contained in the binding core request is responded, the determined at least one processor is smoothly bound with the application program, so that a more matched processor is provided for the application program according to the hardware call requirement, more CPU operation resource support is provided, the operation efficiency of the application program is met, the response speed of the intelligent terminal is improved, and meanwhile, the bad power consumption of the intelligent terminal is reduced.
In this embodiment of the present application, fig. 11 is a schematic diagram illustrating a call between binding core service interfaces.
Referring to fig. 11, in the android system software architecture of the intelligent terminal, at least four independent processes are involved, which are an APP process corresponding to an application layer, a Turbo frame process corresponding to a system frame layer, a Turbo Server process corresponding to a binding core service unit, and a Turbo HAL process corresponding to a hardware abstraction layer in sequence, wherein a communication mechanism between the APP process or the Turbo frame process and the Turbo Server process is registered as a binder service type; the communication mechanism between the Turbo Server process and the Turbo HAL process is registered as a hwbinder service type; the communication mechanism between the Turbo HAL process and Linux kernel is registered as syscall service type.
For example, referring to FIG. 12, the system framework layer triggers a bind core request.
Suppose that a new APP process needs to be created for Activity cold start as monitored by the system framework layer.
In the embodiment of the application, an Activity monitor is embedded in a native Activity cold start flow of an intelligent terminal, and when the Activity monitor (running on a system framework layer) monitors that a new APP process needs to be created for Activity cold start, the intelligent terminal responds to a binding core request triggered by the system framework layer to call a second binding core service interface to send the binding core request to a binding core service unit.
And then, the binding core service unit acquires the hardware parameters of Linux according to the kernel layer according to the third binding core service interface, and determines at least one processor with a binding core relation with the application program corresponding to the service unit identifier contained in the binding core request according to the hardware parameters.
Finally, the binding core service unit sends the binding core relation to the Linux kernel layer, and the Linux kernel layer calls at least one processor according to the binding core relation in response to the hardware call requirement of the application program, so that the cold start of the Activity is optimized and accelerated, and time-consuming operations such as APP resource loading, user Interface (UI) drawing and the like can be completed by utilizing the resources of the at least one processor to the greatest extent, so that the start of the Activity is accelerated.
After the binding method of the processor provided by the embodiment of the present application is described, according to the same inventive concept, the binding device of the processor provided by the embodiment of the present application is described in detail below:
referring to fig. 13, the binding device of the processor includes a sending module 1310, a determining module 1320, a notifying module 1330, and a calling module 1340, specifically:
a sending module 1310, configured to send a core binding request to a core binding service unit in response to a core binding request triggered by the application layer or the system framework layer, where the core binding request includes a service unit identifier that needs to perform a core binding operation;
A determining module 1320, configured to obtain, by the binding core service unit, a hardware parameter of the Linux kernel layer, and determine, according to the hardware parameter, at least one processor having a binding core relationship with an application corresponding to the service unit identifier;
a notification module 1330, configured to notify, by the binding core service unit, the Linux kernel layer of the binding core relationship;
and a calling module 1340, configured to call, by the Linux kernel layer, the at least one processor according to the binding relationship in response to a hardware call requirement of the application.
In some possible embodiments, the application layer triggers the binding core request, and the sending module 1310 is configured to:
triggering the binding core request through the application program layer if the running state of the application program corresponding to the service unit identifier meets a first preset condition;
the system framework layer triggers the core binding request, and the sending module 1310 is configured to:
and if the system framework layer monitors the progress meeting the second preset condition, triggering the core binding request through the system framework layer.
In some possible embodiments, the first preset condition includes that the required resource amount of the application program corresponding to the service unit identifier exceeds a first threshold, and/or the total number of processes included in the application program corresponding to the service unit identifier reaches a second threshold;
The second preset condition includes that the running speed corresponding to the existing process and/or the existing thread is lower than a third threshold value, and/or the Activity cold start needs to be created.
In some possible embodiments, the sending the binding core request to a binding core service unit, the sending module 1310 is configured to:
invoking a first binding core service interface contained in the application program layer or invoking a second binding core service interface contained in the system framework layer, and sending the binding core request to the binding core service unit;
the hardware parameters of the Linux kernel layer are acquired by the kernel binding service unit, and the determining module is used for:
calling a third binding core service interface contained in the binding core service unit, and sending an acquisition request to the hardware abstraction layer, wherein the acquisition request is used for acquiring hardware parameters of the Linux kernel layer;
according to the acquisition request, a fourth binding core service interface contained in the hardware abstraction layer is called, the hardware parameters of the Linux kernel layer are acquired, and the fourth binding core service interface is called and sent to the third binding core service interface;
and the core binding service unit receives the hardware parameters through the third core binding service interface.
In some possible embodiments, the determining module 1320 is configured to determine, according to the hardware parameter, that the application corresponding to the service unit identifier has a binding relationship, where:
acquiring a preset binding core relation set by the binding core service unit, wherein the binding core relation set comprises all service unit identifiers conforming to preset conditions and at least one processor with a binding core relation of each corresponding application program;
and screening out the binding core relation associated with the application program corresponding to the service unit identifier from the binding core relation set according to the hardware parameters, and determining the at least one processor corresponding to the application program according to the binding core relation.
In some possible embodiments, the notifying the Linux kernel layer of the binding relationship by the binding service unit, the notifying module 1330 is configured to:
calling a third binding core service interface contained in the binding core service unit, and sending the binding core relation to a fourth binding core service interface of the hardware abstraction layer;
and calling a fourth binding core service interface contained in the hardware abstraction layer, and sending the binding core relation to the Linux kernel layer.
In some possible embodiments, before the sending of the binding core request to the binding core service unit in response to the binding core request triggered by the application layer or the system framework layer, the sending module 1310 is further configured to:
calling an init daemon by the Linux kernel layer to obtain a configuration file corresponding to the binding service;
and analyzing the configuration file, loading and initializing the binding core service unit.
In some possible embodiments, the configuration file is parsed, the binding core service unit is loaded and initialized, and the sending module 1310 is configured to:
analyzing the configuration file, and executing an initialization CPU parameter process through the hardware abstraction layer to obtain hardware parameters of the Linux kernel layer;
and calling the hardware abstraction layer to register the service type to the HwServiceManager, and registering the service type of the core binding service unit as the Hwbinder service type.
After the binding device of the processor provided in the embodiment of the present application is described, according to the same inventive concept, the following details of the electronic device provided in the embodiment of the present application are described:
referring to fig. 14, the electronic device includes a memory 1401 and a controller 1402, specifically:
A memory 1401 for storing a computer program executable by the controller 1402.
The controller 1402 is connected to the memory 1401 and configured to perform:
responding to a binding core request triggered by the application program layer or the system framework layer, and sending the binding core request to a binding core service unit, wherein the binding core request comprises a service unit identifier which needs to carry out binding core operation;
acquiring hardware parameters of the Linux kernel layer by the kernel binding service unit, and determining at least one processor with a kernel binding relation of an application program corresponding to the service unit identifier according to the hardware parameters;
notifying the Linux kernel layer of the binding relation by the binding service unit;
and responding to the hardware call requirement of the application program, and calling the at least one processor by the Linux kernel layer according to the binding relation.
Having described the electronic device provided by the embodiments of the present application, according to the same inventive concepts, the embodiments of the present application also provide a computer-readable storage medium that, when executed by a processor, enables the processor to perform the method of:
responding to a binding core request triggered by the application program layer or the system framework layer, and sending the binding core request to a binding core service unit, wherein the binding core request comprises a service unit identifier which needs to carry out binding core operation;
Acquiring hardware parameters of the Linux kernel layer by the kernel binding service unit, and determining at least one processor with a kernel binding relation of an application program corresponding to the service unit identifier according to the hardware parameters;
notifying the Linux kernel layer of the binding relation by the binding service unit;
and responding to the hardware call requirement of the application program, and calling the at least one processor by the Linux kernel layer according to the binding relation.
In summary, in the embodiment of the present application, the system software architecture of the intelligent terminal includes an application layer, a system frame layer, a hardware abstraction layer, and a Linux kernel layer from top to bottom, and then, in response to a binding request triggered by the application layer or the system frame layer, the binding request is sent to a binding service unit, where the binding request includes a service unit identifier that needs to perform a binding operation; acquiring hardware parameters of a Linux kernel layer by a binding core service unit, and determining at least one processor with a binding core relation of an application program corresponding to a service unit identifier according to the hardware parameters; notifying the Linux kernel layer of the binding relation by a binding service unit; responding to the hardware call requirement of the application program, and calling at least one processor by a Linux kernel layer according to the binding relation; in this way, a relatively independent binding core service unit is added in a system software architecture of the intelligent terminal, the binding core service unit determines a binding core relation which better meets the requirement of a binding core request according to the acquired hardware parameters of the Linux kernel layer, and the binding core service unit notifies the Linux kernel layer of the binding core relation, so that the degree of freedom and convenience of development in an application program layer and a system framework layer are improved; because the system software architecture adopts a layered architecture, migration adaptation can be rapidly carried out on different hardware platforms, and the complexity of transplanting is greatly reduced; meanwhile, in the embodiment of the application, through the core binding service unit, the core binding can be performed for the application program in a targeted manner according to the characteristics of different performance scenes, so that the running efficiency of the application program is met, and the response speed of the intelligent terminal is improved.
It will be appreciated by those skilled in the art that embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems) and computer program products according to the application. It will be understood that each flow and/or block of the flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart block or blocks and/or block diagram block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.
These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks and/or block diagram block or blocks.
It will be apparent to those skilled in the art that various modifications and variations can be made in the present application without departing from the spirit or scope of the application. Thus, if such modifications and variations of the present application fall within the scope of the claims and the equivalents thereof, the present application is intended to cover such modifications and variations.

Claims (8)

1. The binding method of the processor is characterized in that the binding method is applied to an intelligent terminal, a system software architecture of the intelligent terminal comprises an application program layer, a system framework layer, a hardware abstraction layer and a Linux kernel layer from top to bottom, and the binding method comprises the following steps:
responding to a binding core request triggered by the application program layer or the system frame layer, calling a first binding core service interface contained in the application program layer or calling a second binding core service interface contained in the system frame layer, and sending the binding core request to a binding core service unit, wherein the binding core request contains a service unit identifier needing to carry out binding core operation;
calling a third binding core service interface contained in the binding core service unit, and sending an acquisition request to the hardware abstraction layer, wherein the acquisition request is used for acquiring hardware parameters of the Linux kernel layer;
according to the acquisition request, a fourth binding core service interface contained in the hardware abstraction layer is called, the hardware parameters of the Linux kernel layer are acquired, and the fourth binding core service interface is called and sent to the third binding core service interface;
the binding core service unit receives the hardware parameters through the third binding core service interface, and determines at least one processor with a binding core relation of an application program corresponding to the service unit identifier according to the hardware parameters;
Calling the third binding core service interface to send the binding core relation to the fourth binding core service interface, and calling the fourth binding core service interface to send the binding core relation to the Linux kernel layer;
and responding to the hardware call requirement of the application program, and calling the at least one processor by the Linux kernel layer according to the binding relation.
2. The method of claim 1, wherein the application layer triggering the bind core request comprises:
triggering the binding core request through the application program layer if the running state of the application program corresponding to the service unit identifier meets a first preset condition;
the system framework layer triggers the binding core request, including:
and if the system framework layer monitors the progress meeting the second preset condition, triggering the core binding request through the system framework layer.
3. The method according to claim 2, wherein the first preset condition includes that the required resource amount of the application program corresponding to the service unit identifier exceeds a first threshold value, and/or that the total number of processes contained in the application program corresponding to the service unit identifier reaches a second threshold value;
The second preset condition includes that the running speed corresponding to the existing process and/or the existing thread is lower than a third threshold value, and/or the Activity cold start needs to be created.
4. The method of claim 1, wherein the determining, based on the hardware parameter, that the application corresponding to the service unit identification has a binding relationship comprises:
acquiring a preset binding core relation set by the binding core service unit, wherein the binding core relation set comprises all service unit identifiers conforming to preset conditions and at least one processor with a binding core relation of each corresponding application program;
and screening out the binding core relation associated with the application program corresponding to the service unit identifier from the binding core relation set according to the hardware parameters, and determining the at least one processor corresponding to the application program according to the binding core relation.
5. The method of claim 1, further comprising, prior to responding to a binding core request triggered by the application layer or the system framework layer:
calling an init daemon by the Linux kernel layer to obtain a configuration file corresponding to the binding service;
And analyzing the configuration file, loading and initializing the binding core service unit.
6. The method of claim 5, wherein parsing the configuration file, loading and initializing the binding core service unit comprises:
analyzing the configuration file, and executing an initialization CPU parameter process through the hardware abstraction layer to obtain hardware parameters of the Linux kernel layer;
and calling the hardware abstraction layer to register the service type with the HwServiceManager, and registering the service type communicated with the core binding service unit as the Hwbinder service type.
7. An electronic device, comprising:
a memory for storing a computer program executable by the controller;
the controller is connected to the memory and configured to perform the method of any of claims 1-6.
8. A computer readable storage medium, wherein instructions in the storage medium, when executed by a processor, enable the processor to perform the method of any one of claims 1-6.
CN202111002197.9A 2021-08-30 2021-08-30 Binding method and device of processor and electronic equipment Active CN113760374B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111002197.9A CN113760374B (en) 2021-08-30 2021-08-30 Binding method and device of processor and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111002197.9A CN113760374B (en) 2021-08-30 2021-08-30 Binding method and device of processor and electronic equipment

Publications (2)

Publication Number Publication Date
CN113760374A CN113760374A (en) 2021-12-07
CN113760374B true CN113760374B (en) 2023-04-21

Family

ID=78791719

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111002197.9A Active CN113760374B (en) 2021-08-30 2021-08-30 Binding method and device of processor and electronic equipment

Country Status (1)

Country Link
CN (1) CN113760374B (en)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103176780A (en) * 2011-12-22 2013-06-26 中国科学院声学研究所 Binding system and method of multiple network interfaces
CN107977267A (en) * 2016-10-25 2018-05-01 航天信息股份有限公司 For improving the method and apparatus of one process network program performance
CN108804148A (en) * 2018-05-31 2018-11-13 杭州宏杉科技股份有限公司 A kind of method and device of binding relationship that establishing equipment and driving
CN110955499A (en) * 2018-09-26 2020-04-03 Oppo广东移动通信有限公司 Processor core configuration method, device, terminal and storage medium
CN111625293A (en) * 2020-05-15 2020-09-04 武汉蓝星科技股份有限公司 Terminal dual system based on linux kernel and hardware access management method thereof
CN112416513A (en) * 2020-11-18 2021-02-26 烽火通信科技股份有限公司 Method and system for dynamically adjusting dominant frequency of virtual machine in cloud network
CN113110960A (en) * 2021-04-15 2021-07-13 山东英信计算机技术有限公司 Automatic tuning test method and system based on hard disk performance

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100915803B1 (en) * 2006-12-05 2009-09-07 한국전자통신연구원 Application Program Launching Method and System for Improving Security of Embedded Linux Kernel
US9003410B2 (en) * 2007-01-30 2015-04-07 Hewlett-Packard Development Company, L.P. Abstracting a multithreaded processor core to a single threaded processor core

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103176780A (en) * 2011-12-22 2013-06-26 中国科学院声学研究所 Binding system and method of multiple network interfaces
CN107977267A (en) * 2016-10-25 2018-05-01 航天信息股份有限公司 For improving the method and apparatus of one process network program performance
CN108804148A (en) * 2018-05-31 2018-11-13 杭州宏杉科技股份有限公司 A kind of method and device of binding relationship that establishing equipment and driving
CN110955499A (en) * 2018-09-26 2020-04-03 Oppo广东移动通信有限公司 Processor core configuration method, device, terminal and storage medium
CN111625293A (en) * 2020-05-15 2020-09-04 武汉蓝星科技股份有限公司 Terminal dual system based on linux kernel and hardware access management method thereof
CN112416513A (en) * 2020-11-18 2021-02-26 烽火通信科技股份有限公司 Method and system for dynamically adjusting dominant frequency of virtual machine in cloud network
CN113110960A (en) * 2021-04-15 2021-07-13 山东英信计算机技术有限公司 Automatic tuning test method and system based on hard disk performance

Also Published As

Publication number Publication date
CN113760374A (en) 2021-12-07

Similar Documents

Publication Publication Date Title
WO2020228838A1 (en) Containerized vnf deployment method and related device
US20190391841A1 (en) Execution of auxiliary functions in an on-demand network code execution system
EP3811209A1 (en) Execution of auxiliary functions in an on-demand network code execution system
EP3913859A1 (en) Vnf life cycle management method and apparatus
US20220004410A1 (en) Method For Deploying Virtual Machine And Container, And Related Apparatus
JP2005518015A (en) Middleware service layer for platform systems for mobile terminals
CN108141378B (en) Dormant VDU in VNFD
CN109428764B (en) Virtual network function instantiation method
CN111221618A (en) Method and device for deploying containerized virtual network function
CN104572054B (en) A kind of capacity calling method and equipment
CN110308999B (en) Method for dynamically sharing dependency package between applications, storage medium and mobile terminal
CN112583615B (en) VNF instantiation method, NFVO, VIM, VNFM and system
CN111221630A (en) Business process processing method, device, equipment, readable storage medium and system
CN111858101A (en) Cloud architecture system-oriented adaptation method, device, equipment and storage medium
Justino et al. Outsourcing resource-intensive tasks from mobile apps to clouds: Android and aneka integration
CN112698930B (en) Method, device, equipment and medium for obtaining server identification
CN113760374B (en) Binding method and device of processor and electronic equipment
WO2021097683A1 (en) Android system starting method and apparatus, device, and storage medium
US10872001B1 (en) Big data propagation agent framework
WO2021004320A1 (en) Service resource license management method and related device
CN113064737B (en) Method for enabling components of software communication architecture to run in parallel on multi-core processor
JP4063573B2 (en) Device driver installation / execution method, installation / execution method, and program
CN108804236B (en) AIDL file sharing method and system
US11296929B2 (en) Methods and network systems for enabling a network service in a visited network
KR100981381B1 (en) Device manegement agent and method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant